Talk:Audacity Wiki Home Page

Style "fix" (March 2014)

 * Gale 10Mar14: - I don't like this change http://wiki.audacityteam.org/w/index.php?title=Audacity_Wiki_Home_Page&curid=2845&diff=22086&oldid=22085 because it unbalances the length of the columns. Overdub is strongly related to microphones.
 * Peter 11Mar14: You might similarly argue that "Tapes or Records" and "USB turntables/tape decks" are also similarly closely related. Personally I like bullet points to start list items not appear in the middle of a list item too.  But I think the whole tutorials section needs a working over anyway in the light of the recent Team consensus regarding the documentation of obsolete Audacity versions - so I would be disinclined to worry too much about precise layout details here at thus stage.
 * Gale 11Mar14: There is no "consensus" about removing documentation of obsolete versions of Audacity from Wiki. Ideally the Overdub item would be on a separate line, but it was agreed with James that Wiki home page has a maximum of six rows per section, and that no row of a pair of rows (left and right) should extend more than one line below the other. This "fix" violates that. Similarly, removing the multiple bullets per line from "Operating System Help" would violate that, and look silly. Would you prefer "and" or "&" instead of inline bullet, as we do on http://manual.audacityteam.org/man/Main_Page ?
 * Peter 11Mar14: I would prefer "and" if we are to buddy-up items (I thought Connie frowned an abbreviations like "i.e.", "etc." and "&"). And if we are buddying-up then I do think we should buddy-up "Tapes or Records" and "USB turntables/tape decks" as well as "Mic" and "Overdub" - that way we would have 5 lines per side giving a better balance.
 * Gale 11Mar14: OK, I replaced "&" with "and" per Consistency. I put tapes and records and USB records and tapes in one row, separated by "and". I left "Overdub..." on its own line, which means both blocks in "Top Tutorials... " are one row taller on the left. If you prefer to "rebuddy" Microphone and Overdub separated by "and", please do.
 * Gale 11Mar14: I reduced the space above "Top Tutorials... " to be the same as above the H2's. It looked silly to me as it was. The left-align on "Top Tutorials..." also looks silly to me now it is not at the top. Can we agree to centre it?
 * Peter 12Mar14 @Gale: you write above about style guidelines for the Wiki - but I have never seem those documented. In the Manual we have Connie Consistency to aid us with that - if there are style guidelines here surely they should be documented and linked to in the side nav bar under "For Editors".
 * Gale 13Mar14: There are no style guidelines for this Wiki beyond a presumption that we'll enforce the same principles as on http://manual.audacityteam.org/man/Consistency . This is because members of Audacity Team are now almost the sole editors and because this Wiki has moved "somewhat" to become official documentation. The maximum rows and column offset was something agreed with James when we moved from the old wall of links front page.
 * Peter 14Mar14: Perhaps then we should have a link to Manual>Consistency here in the Wiki-nav-Bar>For Editors. >
 * Peter 14Mar14 later: I went ahead and added such a link.

Comments on position of links to Books about Audacity (March 2014)

 * Gale 10Mar14: Peter moved up the link to Books about Audacity but these books are about legacy versions of Audacity. Even "Audacity 2" is based on a late 1.3 version. Unless a current book is produced I vote to actually move this link to last (lower than it was before).
 * Peter 10Mar14: Fair point - I moved it down, adding a note that it relates to obsolete versions - and modified the target page Books about Audacity noting that all books currently listed refer to obsolete versions of Audacity.

Comments on documentation for compilation by Steve (November 2011)
A recent comment from someone building Audacity on Linux about the documentation (on the wiki) "Lack of clarity/correctness in the docs for building Audacity."

Steve writes: I'm inclined to agree that this area of documentation needs attention and possibly restructuring. Some suggestions that I'd like to raise for discussion:

1) People that are building Audacity from source may not be developers. This is particularly the case on Linux where some users may want to build Audacity because it is not included in their distribution's repository, or the version that is available is too old and buggy or has other problems. In addition to the links on the wiki home page "Guide for New Audacity Developers" and "Guide for Audacity Hackers" it may be useful to have a link to a start page for "Compiling Audacity". That page could be an overview of building Audacity from source, with alternatives such as installing pre-built nightly builds and also link to the existing pages "CompilingAudacityForBeginners", "Developer Guide", "Developing On Windows", "Developing On Mac" and "Developing On Windows".

2) As there is no development work on Audacity 1.2.x and building Audacity 1.2.x requires installing many obsolete packages, the documentation could be simplified by removing all references to building Audacity 1.2.x. If it is considered necessary to keep some documentation about building Audacity 1.2.x it could be demoted to a page on its own, but personally I think that it could just be removed.

3) Suitable versions of WxWidgets are available as packages for most Linux distributions. Building a suitable version of WxWidgets is often the part that users have difficulty with, so I think that instructions for building WxWidgets should be given as a "last resort" method of obtaining WxWidgets.

4) On Windows I think we need a step by step procedure that works for the current Audacity source code on a clean Windows installation (if that is possible). There are too many "see the instructions here..." type comments. While becoming "comfortable with Microsoft's free Visual Studio C++ Express" is important for a developer it is not important for someone that just wants to build Audacity. The priority for most users is just to get a working Audacity.
 * James: For point 4 and windows I disagree. We provide precompiled installers.  Therefore for windows instructions if people just want to build they should instead use those.  We only want to encourage people to build on windows if they are interested in the bleeding edge, and that means they need to be able to debug and be developers who are comfortable with Visual Studio.


 * James: If there are specific wording changes that would make any of the pages clearer make them on the page or on those pages talk pages. On point 3 I am OK with splitting off the 'compiling wxWidgets' part to a separate page.  Likewise 1.2.x (with a banner saying this is for a much older no longer maintained version of Audacity).  On 1 I am OK with experiments in restructuring the build instructions to make them clearer.  I'd like to see some reorganization of Developer Guide too as I find repeating links in the quick links and platform specific guides confusing.

Colour-consistency change 10 July 2010
Agreed with James to change background colour to #EEEEFF which matches with Template:Intro and with colour used on main web site. Also removed some space underneath "Find Pages". Very slight increase to text size and thickness in first two lines for emphasis (header text normally is larger than main text). Size increase only 10% instead of 20% originally proposed because James had minor reservations.

MediaWiki upgrade 26 April 2010
Gale: We are now at latest 1.15.3 of the MediaWiki software.
 * At last - we can have clickable image links where you can resize the images
 * Special:Allpages no longer gives you a list on one page but links to a split list. Sidebar link changed to Special:PrefixIndex which gives half the list with a link to the rest of it.
 * Recent changes contains User Account Creations. I think this is a new feature because there are according to that feature no user account creations prior to April 2010, which is clearly incorrect. You can hide user account creations in Recent Changes if you switch from "All" to "Main" namespace but this doesn't seem to set a cookie so we're stuck with seeing user account creations.

If you find any more "unhelpful" changes post them here - some may be configurable on the server.

Front Page Links
James: How about 'Help us with...' for the help us with link? That page is also about help us as wiki gnomes, and with code, forum, GSoC, quality-systems and campaigns. If someone wants to help we are interested and that is the right page to go to. Gale: It would match with the Sidebar. I slightly feel that if we give examples of how people can help, they may be more likely to click through. I've added "and more..." to see what it looks like, but I don't feel strongly. James: I didn't like it going over two lines, so changed it to the much shorter version. I prefer it shorter, but in no way is that a 'veto' on it being longer than I have made it.

National Flags

 * Gale/James: Decision to use a non-white background, motivated by Finnish flag.

New design 01 February 2010
There is a new Home Page to replace the previous one.

The old design was based on a traditional wiki front page, attempting to give essentially a near-complete list of the perceived most important pages. Some people who were used to this approach and liked to dip in randomly found this worked well. You got a feel for the vast range of content on offer. Others who were looking for help quickly found it more difficult. Partly successful attempts were made to split the design into differently coloured sections, but there was a desire to not make it look like a "patchwork quilt".

Ultimately, we decided on the current simpler design with "For Users" and "For Developers" sections. There are are far fewer links, but we try to make it easier to find "category" or "list" pages that direct people to what they are looking for. We're putting more work into the 'second tier' navigation pages than before.

Developer Section LINK at top

 * Gale: I think if you want a "real time developer news feed" on the front page you/I will need to make sure it is up-to-date. Also unless the developers section has a link at the top of the page I am not sure how many people will see it anyway.
 * James This is the age old problem. We cannot highlight everything because that is like highlighting nothing, only worse.  We cannot have everything at the top of the page.  Rest assured developers will find the developer news.
 * Gale: I'm not suggesting everything, just a link to either the "For Developers" section of the front page, or more likely to the "For Developers" category. "For Developers" is three scrolls down here and I mention it because unbelievably, someone asked me whether the developer stuff was now on its own Wiki! I don't know an elegant answer other than having a fifth "find pages" link at the top called "developers' pages", but I think you should seriously consider it.
 * James: I am OK with not attracting developers who post to an email address rather than scroll down or doing a search in Google. Developers need a lot more gumption than that to get anywhere with the code.
 * Gale: Very droll :=) and I think maybe we discussed before. But actually he isn't a developer, just a subscriber to -devel who likes to follow developer matters. I think he is just highlighting a design issue that there is now no indication from the first scroll that the new Wiki has anything to do with developers at all, and that some users may be (casually) interested in developer stuff.

Anyone can Edit

 * Gale: We've lost the bit of blurb about "what a Wiki is", as I have only just realised. Most users haven't a clue what a Wiki is, I think. I reckon that's worth another four words, don't you?
 * James "Anyone can edit pages to make them more useful or relevant. Click here for help with Wiki editing." = four words? I'd sooner have an invitation to edit the wiki and explanation about how open-source open-content works in Audacity_Wiki:About.  It's at the foot of every page and currently blank.
 * Gale: "Foot of page" is obviously why there is no motivation to do anything about that problem. Maybe forlorn hope, but we would like to encourage contributions, and not have A.N.Novice take one look here, not understand what a Wiki is, and go straight to feedback@ or Forum. We know this happens and I should have noticed this before. "Four words" means having a link obviously (six words if you add "user-editable"). e.g.

Welcome to the user-editable wiki for Audacity&reg; - a free,  open source program for recording and editing sound. It runs on Windows&reg;, Mac OS X, GNU/Linux and other operating systems.

Or if it's important "Audacity" is the first word, the few words can go at the end. Looked at another way - most people who come here know what Audacity is already. Most who come here don't know what a Wiki is. 
 * James: Change made. It is still worth doing something about Audacity_Wiki:About.  It is at the foot of every page and many people arrive at pages directly by search engine.

Dec 2009
Ok, I'm the new guy (here), but I've been a Wikipedian for about 5 years, and was responsible for the MythTV wiki transition to Mediawiki and much of the design there, so hopefully what I have to say here will be useful... and I don't think the old front page is bad at all. I run my text up quite a piece, size-wise, and "Using Audacity" is above the fold, even for me. So that's good. I would swap it to the left column, though, I think. My personal priority layout would be:


 * Whole column:
 * Community


 * Left column:
 * Using
 * Formats
 * Tech
 * Wider World


 * Right column:
 * About
 * Wiki
 * Developing


 * Whole column:
 * Multilingal


 * Otherwise, you're trying to do roughly what the ThinkWiki home page does, by boxing off different categories of items, and it's pretty decent. I think I might try to use *slightly* fewer levels of nested boxes, or alternatively put a break line in above each box's attached label.  And I actually *like* the color coded background idea: one color for user items, one for developer/project items, one for wiki-specific items, and a separate one for "Community", which is sort of broken up into those three categories itself. Oh, and I'd run the lede over white, not a color. --Baylink 09:25, 25 December 2009 (CST)

Requests for edits to Home Page
Currently, only those with Sysop privileges can edit the Home Page.

Please use this section to request any edits you want to make to the Home Page, for example to add a link to a new page you created onto the Home Page, or to correct a typo you spotted. If you make regular and significant contributions to the Wiki and need to edit the Home Page, we'll consider granting you Sysop status, which you can request here.

07 April 2008 Spam filter page saving problem
We had a problem when saving a page that contains new or pre-existing legitimate web addresses, the save was being blocked by the spam filter. We advised users to make a copy of the source then either save the page later, or save it with web addresses removed then resave it later from the copied source. Gale doesn't know exactly what the problem was and as at December 2009, using only our own spam blacklist there doesn't seem to be a problem.

Green Sea
Multinational icon tweaked to show blue sea, not green.

Vandalism and links without spaces
Is it possible to block regular vandals? It's not good to go two days with porn-spam on the front page. Also, some of the links on the main page don't contain fingerspaces. Should they be added? Tommylommykins 10:11, 9 November 2006 (PST) Yes sysops can block vandals indefinitely, prevent them creating accounts and automatically block the last IP address used by the vandal, and any subsequent IPs they try to edit from. We prefer to remove the gophers after external links using CSS.

Orphaned pages
There are really a lot of orphaned pages. The only ways to get to these pages is by hitting the "Random page" link in the navigation bar, by hitting "Special pages" then "Orphaned pages" or by seeing them in the "Recent changes" list soon after they've been made. Someone in charge of the wiki might want to check these pages and either delete them or create links where they would be appropriate. Special:Lonelypages

You will also find that users have created pages for themselves which is redundant. We have user pages that are linked when using our signature with 3 or 4 tilde like this ~ A Witt A Witt 16:05, 20 January 2007 (PST)

Most of the orphaned pages have now been removed. The few remaining pages are still considered for actions. There is also a new page (Pages suggested for deletion) where anyone can suggest pages to be removed. (23:05, 9 July 2007 (PDT))

Words
The front page has instances of both "PlugIn" and "plug-in" and variants thereof. I don't really care which is deemed canonical, but I was trying to search the page for instances of plugin/plug-in so consistency would be a good thing. Perhaps PlugIn was written in camel case out of habit from other wiki systems, which treat those as WikiWords? But MediaWiki doesn't care, so just pick one and standardize it. Thanks, Philip 09:43, 13 March 2006 (PST) Unfortunately as we allow users to freely edit, we'll never get consistency (I'd personally prefer all pages to have spaces between words for the reasons you state). But if any one wants to write a page with suggested standard words and phrases when writing here, go ahead. In the case of plug-ins, Audacity calls its folder "Plug-ins" (hyphenated) and I suspect that usage is the more correct. - Gale

Style
Is there a need for a "style guide" for this Wiki? Recently the pages seem to become more and more colorful, and different editors use color slightly differently. Personally I think it would be a benefit to our readers if we kept to "general Wiki style", with only a few specific "Audacity Wiki styles". It would also benefit the editors, as it would limit the amount of html tags to be used.

Things that there could be a guide for are:
 * Plainlinks or not for external links. (I prefer classic style, i.e. with the trailing little arrow icon.)
 * Use of if you want to ... click here or not. (I prefer writing out a descriptive link name, not just here.)
 * Use of colors.
 * How to format a page intro, before the first heading.

(Suf 23:30, 9 July 2007 (PDT))  Some colouring is I think useful to the users and lack of colour in my opinion is a serious drawback on technical Wiki pages. I think you agree with this for application menu paths (the principle if not the colours). I have been using green for something that is a HINT or an advisory and #BA55D3 for an imperative type of declaration. It is not easy to draw rules about "here" or "descriptive names". Sometime the flow of the text makes it easier to say "you can download the XYZ software [here]." Also can you add a mouseover to links giving a description? Some say you should put a plain text link so you can copy and paste it easier for future use, but that seems to be discouraged on Wikis and should only be done in exceptional cases because of the length of many URLs.  How to format a page intro. might be good. E.g. "_TOC__" to force a table of contents when there are less than four categories is little known. Plainlinks or not are controversial. I hate the classic trailing arrow myself and Wiki and non-Wiki links should display in slightly different colours. Against this Internet Explorer seems to add the space where the trailing arrow would otherwise be anyway, and I have not yet figured a way that makes plainlinks persist across paragraphs in a Wiki so quite a few extra tags are sometimes needed to use them. You can use double breaks within a span as I did here. I think you can go too far regimenting style on a Wiki. It is a place for creation and within reason there ought to be some latitude if what is being done "differently" is an aid to intelligibility. For example someone might come up with something that looked so good that we might want to use it regularly in our own contributions. - Gale

Sound Tracks from within Wikimedia
Are there plans for a demo section of Audacity created sound files here? We would like to be able to reliably create sound tracks and activate them from within wikimedia software at en.wikiversity.org so if a demon section is planned it would be helpful to us if good notes could be taken. If such were emailed to me I could relay them to our developers and users or the notes could be posted here or at en.wikiversity.org as part of some tutorials in building web presence for user products. Thanks for reading! Mirwin 16:00, 3 November 2006 (PST)

Spam Measures
From NT 22:27, 9 October 2007 (PDT)

Q:Can I ask what anti-spam methods have and have not worked well for you here?


 * A:We have an Audacity spam blacklist (blocks spam URLs) which sysops can add to, as well as the Wikimedia blacklist (though this is turned off as it can block page styling).

Q:FWIW I'm involved in another wiki, and we've found that protecting the odd page or 2 has made matters worse, as the spammers then target assorted other pages, which just makes for more revert work.


 * A: Protecting the home page is merely to keep it visible and prevent the hacker posting his tag there (as opposed to link spammers who will almost always target pages well inside the structure anyway). Recaptcha has since been implemented to stop automated registration by spambots.

Q: Meanwhile we arrange the most targeted page so that added spam doesnt display.


 * Gale: Do you mean by using a filter?
 * I didnt set that one up and dont know the details, but i can give you the page addy if you'd like to check it out. It saves us a lot of work. Spammers think they've posted, but it doesnt show to readers.


 * Gale: by all means post the web address here but at the moment it sounds as if some sort of keyword filtering is used. Does the spam poster see it and no-one else? Does that make him stop if he thinks the page will remain, or does he rejoice at his success and spam a lot more (and maybe some it gets past the protection)

Downloads Page

 * I made a new downloads page Downloads Arlen 20:45, 3 July 2009 (PDT)
 * Gale 05 July 09: Thanks for the idea (and for your contributions to Feature Requests). However one of the links you made on the download page was broken, and apart from that, I don't think the page served any purpose given the downloads page on our main site. Also the logo top left of every Wiki page links to our home page and its hover text mentions downloads. If your page had some special content such as tips for downloading, recommended download managers that can cope with redirected links or something like that, well, maybe we can think again. Thanks, anyway.

Logo
Hi, you could reduce your bandwidth and download time (more than 10 secs for dialup-users) if you optimized the Audacity logo on this page.

Using optipng it came down from 82KB to 16KB!:

$ optipng /Users/Shared/NEW_AudacityTransMediaWiki.png OptiPNG 0.4.8: Advanced PNG optimizer. Copyright (C) 2001-2005 Cosmin Truta.

155x135 8-bit RGB-alpha non-interlaced Input file size = 84104 bytes Input IDAT size = 83856 bytes Trying... zc = 9 zm = 8  zs = 0  f = 0         IDAT size = 17869 zc = 9 zm = 8  zs = 1  f = 0         IDAT size = 17198 zc = 1 zm = 8  zs = 2  f = 0         IDAT size = 25517 zc = 9 zm = 8  zs = 3  f = 0         IDAT size = 19472 zc = 9 zm = 8  zs = 0  f = 5         IDAT size = 15565 zc = 9 zm = 8  zs = 1  f = 5         IDAT size = 14284 zc = 1 zm = 8  zs = 2  f = 5         IDAT too big ... abandoned at 97.77% zc = 9 zm = 8  zs = 3  f = 5         IDAT size = 13714
 * Processing /Users/Shared/NEW_AudacityTransMediaWiki.png

The best parameters are: zc = 9 zm = 8  zs = 3  f = 5         IDAT size = 13714

New file size = 13842 bytes (70262 bytes decrease) New IDAT size = 13714 bytes (70142 bytes = 83.65% decrease)

I uploaded the optimized image: http://wiki.audacityteam.org/images/a/a7/NEW_AudacityTransMediaWiki.png