Talk:Proposed Front Page

From Audacity Wiki
Jump to: navigation, search
The proposed front page will go live in early February 2010 (agreed in e-mail between James and Gale).

Translations

Gale 16 Jan09: I see AlexH has started some pages in German. Have we got a policy on how to handle these? In the Manual there won't be foreign language pages without an English equivalent; here, most could have no English equivalent. Do you always want the home pages to be "XX Front Page" where "XX" is the language name written in English? AlexH has chosen "De" as his front page with other pages inside that structure. I think this is reasonable if he incorporates the information from German Information into De, and De becomes the German front page? And then OK to have page titles in German, even if it's actually a translation of an English page, because we'll probably never be able to keep English and foreign versions synchronised?

  • James 16 Jan09: We don't have a policy yet. I have a concern about foreign language spam and do not know an answer to that one. Looking at wikipedia there is no 1-1 correspondence between foreign language pages and english versions and I am just fine with that for both our wikis. IMHO in the manual we should not bundle the foreign language pages, but at the moment the volume of them is sufficiently low that it really does not matter. I'm not against the 'de/namen' vs 'nom/fr' for a translation of a page called 'name'. If anything it is marginally more logical. I would not want to ask Olivier to follow suit. Basically I would like to leave it to the foreign language contributors to sort out. If AlexH stays around inviting him to the manual wiki might be good. If you would like a policy to ensure consistency, and to ask AlexH to change, I would support that (and help by moving existing articles).
  • James (later): Wikipedia gets the language links (for translated pages) to show in the sidebar using this. Looks like that's not implemented for our installation, and could be worth doing if the language content grows.

Some Design Aspects

  • Lots of Tutorial links and they are almost at the top. Lists kept shorter by dividing into 'from...' and 'to...', not perfect but a clearer distinction than Tips vs Tutorials vs 'Troubleshooting'.
    • Gale: Well, maybe. If the tips/tutorials distinction was clearer (or tips/tutorials were grouped, which is an unexplored idea I think could work), I might not agree. I don't (yet) regard this as final, but that depends on finding something better.
  • Top Tutorials title to let users know that these are not all the tutorials.
  • Calls 'Help' 'Help' . Using 'Support a.k.a Help' not good, nor is the '<--Ask Here' arrow. Solution suggested by Gale adopted.
  • Find box at top of page. "Search Wiki by category" moved from bottom of page to a "Find Pages" section so we can have less top and bottom padding.
    • Gale: "Excess" padding above the flags seems to have appeared again.
      • Gale: I agree - mostly that doesn't look better, except at the top. I've not looked at your code, but if you reverted the "more cramped" edit, can you get the space between the flags and the text above the same as the space between the bottom of the last table and the page bottom? Having so much more space at the top really looks odd to me, anyway.
  • Small flag links and names of localised pages are now on the same footing (using redirects).
  • FAQ spelt out in full, increases chances of people new to it understanding.
  • Discussion Forum, not just Forum, increases chances of people new to it understanding.



Current Discussion

  • Gale: Colours: I've felt for a long time that something's not quite right here. We have a bold minimal design but staid (?) colours. I've some idea of that dark Audacity blue as a background looking quite nice - did you ever try that? That leaves some decision on what to do about the top two lines, but maybe something could be done. If this was a "real" web page a background image something like the Audacitystore image might be nice.
  • Gale: As for the structure "Audio from, Audio to", I don't think it's 100% right yet. For example, having link text to "CD" and "Computer or CD" is a bit confusing. USB turntables are "Audio in" but other turntables are both "Audio in" and "Audio out". Perhaps "Stereo to Mono" isn't important enough to have a link for 2.0 since there is a one-step command now.</p>

    My feeling is there is far too much padding around the white tables. It's very noticeable between the introductory text at the top and the flags. In IE6, which still has more % share than other IE versions, the left padding isn't there at all.

  • James: Gale, do feel free to change the selection of links. You know best what links matter most - what I care about here is long bulletted lists, and in this context 6 in each list is my personal max. I do think the new subheads solve the big problem we had of how to sub-classify the tutorials and how to get more tutorial links on the front page.
  • James: Instead of 'Top Tips & Tutorials' 'Popular Tips & Tutorials' might work too. Your call. Just change it if you prefer it and deleted this comment either way.
  • James: I have yet to see a home turntable that can record to vinyl! I think 'turntable' is OK in 'from..', but I agree 'deck' might be in both 'from..' and 'to..' if we had it. The from/to distinction might justify splitting some big tutorials but I'd need to look into it.
  • James: Once we've agreed a layout that we're both happy with in Firefox I can work to make it work in IE6 too.
  • Gale: Noted the new "Find Pages" section in the Summary, thanks. Better than before, but not sure whether we want an explicit "Find" section or not, it does break your neat "For Users/For Developers" design a little. I'd see a find by category link as being better at the top really as it does stand outside all the sections (as per your original idea, except it was too hard to find).
  • Peter: In the For Developers section is the "Reference" in "Reference Documentation" meant to be italicized? It looks odd like this. Also the title "Developer News" is centred and not over the bullet points (I suspect that you meant to centre the bullet points too to make the alignment?).

Info

  • Flags with alt text will probably need MediaWiki 1.14+ and [[File:image.png|link=http://www.link.com|120px|alt=alttext]]
  • Developer News (item on front page at any rate) can survive on four news items a year.


Older Discussion (2)

  • Gale 29 Apr 09: I found a couple of nice search extensions that actually find pages irrespective of the case/spacing of their titles, but never got round to writing to Buanzo about it. I'll post the links to those extensions here when I can figure where I put them.
  • Gale: I think "everything for everyone else" as a link title is near-comical, we could not go live with that. I don't think we want a "For Document Editors" panel. Maybe we do want a link to a category for them, but even that is questionable given the interest.
  • James: Maybe instead of "everything for everyone else" we could have 'Search Wiki by Category' and link to Category:Category. Obviously Category:Category would have to be modified/improved for that role.
  • Gale: One thing I think we must be on our guard about with linking "Everything for Users" to Category:For Users is the misleading impression that Articles in category "For Users" is actually a list of articles that is inside an "tree" of that name as per normal internet structure.
  • James: OK. I've no problem with making our categories more tree-like in exactly the way you experimented with. We actually already have a similar situation with GSoC being part of For Developers.
    • Technically what we have is a 'directed acyclic graph' not a tree. It is this which solves our classification/Navigation problem. Something like Feature Requests is relevant to both users and to developers. With categories it can be tagged for both those categories. We are still tree like.
I'll start updating Category:Category to try and make it better for the finder page role.
  • Gale: Although of course it looks very clean with only four bullet points in "Tips and Tutorials", really with only three very highly specific items, it's not even worth having them. If I saw that, I'd think "if that's all they got, why bother".


Summary of Past Discussion

Summary by James 15:11, 10 September 2008 (PDT):

Still Being Sorted

  • There is competing pressure for more/fewer links, with the pressure being most intense for the tutorial/tip/help links. Gale favours 12 tutorials/tips links, with a possible fallback of having a few categories. James reckons there are 51 tutorials/tips competing for front page attention and prefers having 3 links to give an idea of what the topics tutorials and tips deal with and a link to a page that gives the full list of tutorials and tips.
  • Gale willing to try to organise the Tutorials page for faster finding.
  • All XYZ links at bottom right for each main section.
  • Gale not keen on the 'waste of space' in the tutorials/tips section. James sees the space as necessary to avoid the 'wall of text' problem.
  • Gale: Blender have more links than we do, and avoid the "wall" with a three column layout.


Largely Agreed

  • Core Documentation too Geeky a phrase.
  • Developer section can rely on developers being savvy enough to drill down deeper.
  • Meta is confusing as a title.
  • A Meta and 'how to edit' category was too big. Contributors to wiki will 'get there' via participation links.
  • Troubleshooter and Navigation pages will be deleted once we have categories pages working better.


Other Issues...


Older Discussion (1)

  • Gale 11Sep08: 02:32 UTC: OK I've caught up now and the proposal is to have mutually exclusive categories for the three panels. I've mulled this over off and on for the last few hours and this is my feeling. I'm obviously in disagreement about using this word "documentation" in the top level panels. I think it's a major "turn-off" for more casual users, and it's forcing us into the third "Audacity & Beyond" category where perhaps we don't need it.
    • This category will always be hard to tie down as to what it is.
    • Of the items listed in it now, everything except "Programs based on Audacity" is "Users"
    • Audacity is not something used in isolation and will become less so.
    So my thinking is to have just two panels: "users" and "developers". Either tag "Audacity & Beyond" onto the bottom of "Users", and the link to "All users pages" goes at the end of the top level panel, as now. Or, take whatever we think is *really" indispensable as a front page link and work it into "Users", with or without new column headings.
    • "Created Using Audacity" is close to "Music" (and is the only realistic link for "Music" this until we support audio upload).
    • More about digital audio" is close to "Resources"
    • "Link exchange" is close to "Participation"
    Whichever we do is I think easier than struggling with this third "catch-all" category.
    As for the number of links in Tips and Tutorials, Blender have more than we do, and avoid the "wall" with a three column layout. If Tips and Tutorials is longer than the other columns, that helps avoid the wall. Did you have a reason for rejecting that idea? For me the current "wide box at the bottom of the panel" still looks uncomfortable, especially "Audacity Developer News" with only three bullets and the long right-floated text.


Hacker's Guide

  • Gale: I have not actually grasped yet what "Hacker's Guide" is supposed to be. I guess it's meant to be for experienced developers who want to get into modifying the code? Can we think of a more politically correct phrase?
  • James: That's the intention. Hackers is now a politically correct term. O'Reilly have been rehabilitating the term using their 'Hacks' series of books. White hat hackers are particularly good guys, and evil black hat hackers should now really be known as crackers (or l33t warez merchants or some such if they are still close to being script kiddies).