Re: Lilypond Website Work
Carl Peterson carlopeter...@gmail.com writes: On Sun, Dec 8, 2013 at 5:55 PM, Carl Peterson carlopeter...@gmail.comwrote: I have something in development for #2 on Federico's list. I've parsed through enough of the texi2html script that I was able to insert CSS classes into the body tag that will allow me to color code each manual. One thing that is very strange that I've noticed in working on this is that if I modify Documentation/lilypond-texi2html.init (which impacts virtually every part of the website) and build the documentation, nothing happens, but if I change one of the stylesheets (which is a superficial thing that does not, to my knowledge, impact the building of any other file), the entire documentation gets rebuilt. This is backwards. When I've been working on the lilypond-texi2html.init file, I've been having to go in and touch one of the manual pages (usually changes.tely, since it's probably the smallest and easiest to build) to get it to recompile that manual so I can see what my changes did. If you feel comfortable figuring out what change would be required to the makefiles or makefile inclusion files, you can propose a patch after checking it does what you think it does. Other than that, report a bug. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
2013/12/9 Carl Peterson carlopeter...@gmail.com: 2013/12/6 David Kastrup d...@gnu.org: A complete color _scheme_ might be distracting, but it may make sense to have a title or side bar or other obvious always on-screen element color-coded. Okay, so I have a patch set ready to go with this. The only differences are that the Usage book is yellow, the Internals book is purple, and I made the Contributor's Guide black. Where should I submit the patches for review? I've tried reading the Contributor's Guide and I come up with about 3 or 4 different methods, and this sort of work is kind of in a no-man's land anyway. Please upload it using git cl tool, as described in http://www.lilypond.org/doc/v2.17/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review After doing so, there should be a new issue in the tracker (http://code.google.com/p/lilypond/issues/list) about your patch, and inside that issue there should be a link to http://codereview.appspot.com/something If you have problems, let us know. thanks! Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
Il 09/dic/2013 09:22 Janek Warchoł janek.lilyp...@gmail.com ha scritto: 2013/12/9 Carl Peterson carlopeter...@gmail.com: 2013/12/6 David Kastrup d...@gnu.org: A complete color _scheme_ might be distracting, but it may make sense to have a title or side bar or other obvious always on-screen element color-coded. Okay, so I have a patch set ready to go with this. The only differences are that the Usage book is yellow, the Internals book is purple, and I made the Contributor's Guide black. Where should I submit the patches for review? I've tried reading the Contributor's Guide and I come up with about 3 or 4 different methods, and this sort of work is kind of in a no-man's land anyway. Please upload it using git cl tool, as described in http://www.lilypond.org/doc/v2.17/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review After doing so, there should be a new issue in the tracker (http://code.google.com/p/lilypond/issues/list) about your patch, and inside that issue there should be a link to http://codereview.appspot.com/something I've already created the issue in the tracker. Carl, put the issue number in your commit message and IIRC git-cl will be able to understand ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
2013/12/6 Federico Bruni fedel...@gmail.com These problems should be recorded in our tracker. So far I've seen 2 issues/feature requests: 1. improve SEO 2. associate a different color scheme to each manual I've added them: https://code.google.com/p/lilypond/issues/detail?id=3714 https://code.google.com/p/lilypond/issues/detail?id=3715 This is the list of issues when searching website in our tracker: http://code.google.com/p/lilypond/issues/list?can=2q=website colspec=ID+Type+Status+Stars+Owner+Patch+Needs+Summaryx=typecells=tiles A label:Website may be useful? No, label is not what we need. We might need a new Type. Or we can keep using type:Documentation and add website: on the subject of the issue. Who wants to work on the website should find all the relevant issues with these keywords: website type:Documentation ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
Am 08.12.2013 23:23, schrieb Federico Bruni: 2013/12/6 Federico Bruni fedel...@gmail.com mailto:fedel...@gmail.com These problems should be recorded in our tracker. So far I've seen 2 issues/feature requests: 1. improve SEO 2. associate a different color scheme to each manual I've added them: https://code.google.com/p/lilypond/issues/detail?id=3714 https://code.google.com/p/lilypond/issues/detail?id=3715 Two more I noticed: 1) Distinguish between internal and external links? Should be fairly easy through CSS. 2) Actually you're not really seeing on which page you're on because the only reference is a very small highlighting of the active menu item. I suggest to automatically place the @node name as a @heading on top of each website page. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
On Sun, Dec 8, 2013 at 5:34 PM, Urs Liska u...@openlilylib.org wrote: Am 08.12.2013 23:23, schrieb Federico Bruni: 2013/12/6 Federico Bruni fedel...@gmail.com These problems should be recorded in our tracker. So far I've seen 2 issues/feature requests: 1. improve SEO 2. associate a different color scheme to each manual I've added them: https://code.google.com/p/lilypond/issues/detail?id=3714 https://code.google.com/p/lilypond/issues/detail?id=3715 Two more I noticed: 1) Distinguish between internal and external links? Should be fairly easy through CSS. 2) Actually you're not really seeing on which page you're on because the only reference is a very small highlighting of the active menu item. I suggest to automatically place the @node name as a @heading on top of each website page. Urs I have something in development for #2 on Federico's list. I've parsed through enough of the texi2html script that I was able to insert CSS classes into the body tag that will allow me to color code each manual. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
On Sun, Dec 8, 2013 at 5:55 PM, Carl Peterson carlopeter...@gmail.comwrote: I have something in development for #2 on Federico's list. I've parsed through enough of the texi2html script that I was able to insert CSS classes into the body tag that will allow me to color code each manual. One thing that is very strange that I've noticed in working on this is that if I modify Documentation/lilypond-texi2html.init (which impacts virtually every part of the website) and build the documentation, nothing happens, but if I change one of the stylesheets (which is a superficial thing that does not, to my knowledge, impact the building of any other file), the entire documentation gets rebuilt. This is backwards. When I've been working on the lilypond-texi2html.init file, I've been having to go in and touch one of the manual pages (usually changes.tely, since it's probably the smallest and easiest to build) to get it to recompile that manual so I can see what my changes did. Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
On Fri, Dec 6, 2013 at 3:26 AM, Janek Warchoł janek.lilyp...@gmail.comwrote: 2013/12/6 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: A suggestion from my colleague: for a long time he kept confusing LM and NR, and he said that it would be nice if (for example) they had different color schemes so that one will know where to look at things (hmm, i remember seeing it in the blue manual...). Learning - Green book Using - White book Notation - Blue book Extending - Red book Internals - Black book A complete color _scheme_ might be distracting, but it may make sense to have a title or side bar or other obvious always on-screen element color-coded. +1 Okay, so I have a patch set ready to go with this. The only differences are that the Usage book is yellow, the Internals book is purple, and I made the Contributor's Guide black. Where should I submit the patches for review? I've tried reading the Contributor's Guide and I come up with about 3 or 4 different methods, and this sort of work is kind of in a no-man's land anyway. Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
Am 06.12.2013 09:12, schrieb Janek Warchoł: 2013/12/6 Carl Peterson carlopeter...@gmail.com: Having worked for two corporations that have fairly extensive (and stringent) visual identity and branding guidelines (colors, typeface, formatting, etc.), I've learned that there are ways to make an obvious change between two things while still making them look like they go together. A suggestion from my colleague: for a long time he kept confusing LM and NR, and he said that it would be nice if (for example) they had different color schemes so that one will know where to look at things (hmm, i remember seeing it in the blue manual...). Janek As can be seen here (one more time): Am 07.12.2013 08:45, schrieb Janek Warchoł: 2013/12/7 David Bolton davidkbol...@gmail.com: ... And by the way, why are you using documentation for versions 2.16 and 2.17 while the file is marked as 2.14? This looks like a bad idea. best, Janek It may also be a good idea to find a way to visually distinguish between the stable and the development sections of website/manual? Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
2013/12/7 David Kastrup d...@gnu.org: It may also be a good idea to find a way to visually distinguish between the stable and the development sections of website/manual? Stable: solid color in the color coded area. Development: diagonally striped or patterned in some other way. +1 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
On 12/7/2013 6:39 AM, Urs Liska wrote: As can be seen here (one more time): Am 07.12.2013 08:45, schrieb Janek Warchoł: 2013/12/7 David Bolton davidkbol...@gmail.com: ... And by the way, why are you using documentation for versions 2.16 and 2.17 while the file is marked as 2.14? This looks like a bad idea. best, Janek It may also be a good idea to find a way to visually distinguish between the stable and the development sections of website/manual? Maybe it is helpful to know that I got to the manual page from a web search. I realized that I was on the wrong version because of the URL, but there is no easy way to get to the right version. For example, manually changing the version number in the URL never seems to work (it gives 404 errors), and there are no links on the page to the equivalent documentation for other versions. My recommendations would be: 1. Use a consistent URL for the latest stable version of LilyPond documentation. That way web searches and other pages across the web link to the latest version instead of ancient versions of the documentation. 2. On old or unstable documentation include a link to the equivalent page in the stable version of the documentation. David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
On 12/7/2013 9:48 AM, Janek Warchoł wrote: 2013/12/7 David Kastrup d...@gnu.org: It may also be a good idea to find a way to visually distinguish between the stable and the development sections of website/manual? Stable: solid color in the color coded area. Development: diagonally striped or patterned in some other way. +1 For me, it had more to do with the difficult of moving to the place I was suppose to be (and assuming that the current page was good enough). For comparison MuseScore only shows the latest version online (with references inline to old versions when necessary). Finale supports hacking of the URL. For example visit the following page and then replace 2012 with 2011: http://www.finalemusic.com/UserManuals/Finale2012Mac/Content/Finale/MMMTRDLG.htm Microsoft Office shows version information in the search results: http://office.microsoft.com/en-us/word-help/results.aspx?qu=insert+a+pictureex=1origin=HP005189866 David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
On Sat, Dec 7, 2013 at 3:42 PM, Phil Holmes m...@philholmes.net wrote: My recommendations would be: 1. Use a consistent URL for the latest stable version of LilyPond documentation. That way web searches and other pages across the web link to the latest version instead of ancient versions of the documentation. Unfortunately, this is not possible. The released stable version is currently 2.16. However, it seems that a number of packagers are significantly behind this, using 2.14. We can't link to a single stable version when there are 2 or more. I think the suggestion is basically (until 2.18 is released) to use the .htaccess file to redirect http://lilypond.org/doc/stable -- http://lilypond.org/doc/v2.16 http://lilypond.org/doc/dev -- http://lilypond.org/doc/v2.17 When 2.18 is released, then the .htaccess file is modified to redirect http://lilypond.org/doc/stable -- http://lilypond.org/doc/v2.16 Since this would be defined on the .htaccess, should be transparent to the user and requires no duplication of files. If you want to get really picky, there are still things I've seen using 2.12. I don't know that means we have keep track of what versions are packaged with what. After all, if someone posts something here that doesn't use 2.16 or 2.17, almost uniformly, it will be strongly suggested to that individual that they ought to update to the latest. 2. On old or unstable documentation include a link to the equivalent page in the stable version of the documentation. Generally, this does work - replacing the version number in the URL brings up an older version of the manual. If it is a 404, it must be that this page did not exist in the old version. If you're using an outdated version, it might make sense to download the appropriate PDF manuals. I believe the suggestion is to go in the other direction---if the search happens to drop you into an older version, provide a link to the most recent. The problem here, I think, is technical. Short of .htaccess or some other server-side wrapper (similar to what many free web hosting providers do) that will put a banner saying, This is not the latest version. Click here to go to..., because of the nature of updating the website, I don't know how practical this is, to go through and recompile all the prior versions of documentation to provide convenient links. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
2013/12/6 Carl Peterson carlopeter...@gmail.com: Having worked for two corporations that have fairly extensive (and stringent) visual identity and branding guidelines (colors, typeface, formatting, etc.), I've learned that there are ways to make an obvious change between two things while still making them look like they go together. A suggestion from my colleague: for a long time he kept confusing LM and NR, and he said that it would be nice if (for example) they had different color schemes so that one will know where to look at things (hmm, i remember seeing it in the blue manual...). Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
Janek Warchoł janek.lilyp...@gmail.com writes: 2013/12/6 Carl Peterson carlopeter...@gmail.com: Having worked for two corporations that have fairly extensive (and stringent) visual identity and branding guidelines (colors, typeface, formatting, etc.), I've learned that there are ways to make an obvious change between two things while still making them look like they go together. A suggestion from my colleague: for a long time he kept confusing LM and NR, and he said that it would be nice if (for example) they had different color schemes so that one will know where to look at things (hmm, i remember seeing it in the blue manual...). Learning - Green book Using - White book Notation - Blue book Extending - Red book Internals - Black book A complete color _scheme_ might be distracting, but it may make sense to have a title or side bar or other obvious always on-screen element color-coded. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
2013/12/6 David Kastrup d...@gnu.org: Janek Warchoł janek.lilyp...@gmail.com writes: A suggestion from my colleague: for a long time he kept confusing LM and NR, and he said that it would be nice if (for example) they had different color schemes so that one will know where to look at things (hmm, i remember seeing it in the blue manual...). Learning - Green book Using - White book Notation - Blue book Extending - Red book Internals - Black book A complete color _scheme_ might be distracting, but it may make sense to have a title or side bar or other obvious always on-screen element color-coded. +1 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
Carl, you might also like to keep in mind Lilypond's search rankings while you redesign. A first page listing would bump up traffic considerable, and shouldn't be hard to achieve given that whoever designed lilypond's homepage hasn't given any thought to SE ranking - there's just no relevant text. (might rank well with We are happy/pleased/proud to announce though). google search term: music notation software 1. musescore.org 2. sibelius.com 3. finalemusic.com . 18. lilypond.org google search term: free music notation software 1. musescore.org 2. finalemusic.com 3. noteflight.com . 200 lilypond.org (couldn't find it - I stopped at page 20) Phil. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
2013/12/6 Phil Burfitt phil.burf...@talktalk.net Carl, you might also like to keep in mind Lilypond's search rankings while you redesign. A first page listing would bump up traffic considerable, and shouldn't be hard to achieve given that whoever designed lilypond's homepage hasn't given any thought to SE ranking - there's just no relevant text. (might rank well with We are happy/pleased/proud to announce though). :-) google search term: music notation software 1. musescore.org 2. sibelius.com 3. finalemusic.com . 18. lilypond.org google search term: free music notation software 1. musescore.org 2. finalemusic.com 3. noteflight.com . 200 lilypond.org (couldn't find it - I stopped at page 20) This is really bad, I never checked it. These problems should be recorded in our tracker. So far I've seen 2 issues/feature requests: 1. improve SEO 2. associate a different color scheme to each manual This is the list of issues when searching website in our tracker: http://code.google.com/p/lilypond/issues/list?can=2q=websitecolspec=ID+Type+Status+Stars+Owner+Patch+Needs+Summaryx=typecells=tiles A label:Website may be useful? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
Federico Bruni writes: 2013/12/6 Phil Burfitt phil.burf...@talktalk.net Carl, you might also like to keep in mind Lilypond's search rankings while you redesign. This is really bad, I never checked it. 1. improve SEO I guess I'm glad someone notices and seems to care http://lists.gnu.org/archive/html/lilypond-user/2009-11/msg00258.html at last... Greetings, Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
A side comment, picking up on a comment in the Windows experience thread: I hope the new site will avoid any hooks to Google analytics or other APIs. I'm behind the Great Firewall of China, and I see frequently how Google dependencies cause page loading times to balloon, while the browser waits for blocked connections to time out. This is one of the rare times when I can complain about that problem *before* the problem gets built into yet another website :-) hjh ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
Am 06.12.2013 14:12, schrieb Federico Bruni: These problems should be recorded in our tracker. So far I've seen 2 issues/feature requests: 1. improve SEO 2. associate a different color scheme to each manual I think although not explicitly stated as a feature request the discussion surely yields 3. Clarify first steps/new user experience. Obviously it isn't clear enough what a new user has to expect from a text based notation program. If I follow the trail from the front page I will read a) Introduction. OK, this doesn't tell me anything about how I'd have to work with LilyPond, but that's OK for that page (IMO) b) Features. This is problematic, I think: - The Elegance box is OK, but I'm not sure why this is on a different page than Our Goals on Introduction. - Ease of use. I have several problems with this box - Text based input. Actually this says that you edit text files in an editor. But it does nothing to explain the concept who doesn't know about it already. The input contains all the information, so there is no need to remember complex command sequences: simply save a file for later reference I think this is simply misleading. - Mix music and text is actually a feature but doesn't have to do with Ease of use. - Extensible design with Scheme absolutely doesn't belong to Ease of use. c) Environment - I think the Editors section should be first here. OK, Free Software is important, but I think at least at this point the user should finally be told what kind of tool he is suggested to download: - Currently the Editors section sounds too optional, something like: If you want you also can try alternative editors. The term Easier Editing is suggesting this too. As a new user I'd probably think: OK, I'll come back to this but first I'll give it a try with the built-in editor :-( So: - make it explicit that LilyPond itself doesn't have a GUI and will only process text files it is given. - make it explicit that you have to use an editor for this. - Say that it's part of the beauty of text based tools that you can use _any_ text editor, but that it is highly recommended to use one of the available dedicated GUI programs. - Suggest Denemo and Frescobaldi as appropriate tools (maybe giving a few hints about their characteristics) and say that these tools will take care of installing LilyPond too. This can be quite short but should definitely contain a link to the Text input page. This is actually very useful in our context, but again the section about Easier Editing isn't explicit enough. Somehow this give the impression we're somehow ashamed of something. In any case the message is too weak. The user _has_ to know he's going to use a compiler and needs a programmer's editor for that. (Of course worded less bluntly). ### This isn't a one should post. I'm ready to contribute to this, as long as it is clear that changing contents on this level doesn't interfere with other current ideas of restructuring the web site. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
Urs Liska m...@ursliska.de writes: Am 06.12.2013 14:12, schrieb Federico Bruni: These problems should be recorded in our tracker. So far I've seen 2 issues/feature requests: 1. improve SEO 2. associate a different color scheme to each manual I think although not explicitly stated as a feature request the discussion surely yields 3. Clarify first steps/new user experience. I don't think that this is the same topic. The listed requests are about the web site representation and possible restructuring, but you talk about content details. They may be worth amending, but that's not the Website Work that Carl is thinking about doing. It has nothing to do with website programming. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
On Fri, Dec 6, 2013 at 9:00 AM, James Harkins jamshar...@gmail.com wrote: A side comment, picking up on a comment in the Windows experience thread: I hope the new site will avoid any hooks to Google analytics or other APIs. I'm behind the Great Firewall of China, and I see frequently how Google dependencies cause page loading times to balloon, while the browser waits for blocked connections to time out. This is one of the rare times when I can complain about that problem *before* the problem gets built into yet another website :-) hjh This is one of a number of targets of what I would like to eventually work through, particularly: 1) No external server dependencies. This includes jQuery, external analytics, web font services, or any such things. Each of these are additional calls that make things take longer. I've mentioned on the previous thread that if the server has the capability, I would, at some point, like to look into an internal analytics system. 2) No extraneous file loads. While there will be a separate CSS file (as there is now), I want to eventually eliminate any image file that does not contribute to content. The first victim of this will be the gradient images used for the header and navigation backgrounds. CSS gradients can be coded for fewer bytes and one less server request, with graceful degradation if CSS3 is not available on a browser. Regarding #2, this does not necessarily mean no images. I think we actually need *more* images. However, I think the images that we do have need to be content (examples of music, etc.), not window-dressing. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
- Original Message - From: Carl Peterson I want to eventually eliminate any image file that does not contribute to content. The first victim of this will be the gradient images used for the header and navigation backgrounds. CSS gradients can be coded for fewer bytes and one less server request, with graceful degradation if CSS3 is not available on a browser. TBH, this is a complete waste of time. The image files are minuscule and affect loading time zilch. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work
Phil Holmes m...@philholmes.net writes: - Original Message - From: Carl Peterson I want to eventually eliminate any image file that does not contribute to content. The first victim of this will be the gradient images used for the header and navigation backgrounds. CSS gradients can be coded for fewer bytes and one less server request, with graceful degradation if CSS3 is not available on a browser. TBH, this is a complete waste of time. The image files are minuscule and affect loading time zilch. They don't affect the network capacity significantly, but if they are fetched via a different TCP connection on a congested network, they may at times arrive later than other content. So for incrementally rendering browsers, this may occasionally improve flashing of the page updates. And graceful degradation is nice for text browsers. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
- Original Message - From: Phil Holmes m...@philholmes.net Sent: Friday, December 06, 2013 3:35 PM Our server is provided on a goodwill basis, and so we would not want to use any scripting that might load it. Carl Perterson wrote: CSS gradients can be coded for fewer bytes and one less server request, with graceful degradation if CSS3 is not available on a browser. TBH, this is a complete waste of time. The image files are minuscule and affect loading time zilch. For every image link in an html page, a browser makes another http request to get that image! You said you want to save server load? Phil. Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
- Original Message - From: Phil Burfitt phil.burf...@talktalk.net To: Phil Holmes m...@philholmes.net; Carl Peterson carlopeter...@gmail.com; James Harkins jamshar...@gmail.com Cc: Mailinglist lilypond-user lilypond-user@gnu.org Sent: Friday, December 06, 2013 3:59 PM Subject: Re: LilyPond Website Work (was: A thought on Windows Experience) - Original Message - From: Phil Holmes m...@philholmes.net Sent: Friday, December 06, 2013 3:35 PM Our server is provided on a goodwill basis, and so we would not want to use any scripting that might load it. Carl Perterson wrote: CSS gradients can be coded for fewer bytes and one less server request, with graceful degradation if CSS3 is not available on a browser. TBH, this is a complete waste of time. The image files are minuscule and affect loading time zilch. For every image link in an html page, a browser makes another http request to get that image! You said you want to save server load? Phil. Well, yes, as CPU load. I remain of the view that this is not a good use of time - there are other things that will be of greater value for less effort. Remember, you'll not be doing this by editing HTML, but the texi2HTML control files. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
On Fri, Dec 6, 2013 at 11:08 AM, Phil Holmes m...@philholmes.net wrote: Well, yes, as CPU load. I remain of the view that this is not a good use of time - there are other things that will be of greater value for less effort. Remember, you'll not be doing this by editing HTML, but the texi2HTML control files. From looking at the git repo, I was under the impression that changing the background image of the header would be handled by a CSS file, which appears to exist as a monolithic css file in the repo. So that would be a direct edit. That's why the facelift is item #1 on my list, because it requires the least technical knowledge to make happen. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
I just did a Google search on a computer that I've never used/logged into before. My account was fresh, and I did these searches without any previous history affecting my results: Music notation software Lilypond came in at 25. Free music notation software It came in at 11. Free music typesetting software It was 7. Music typesetting software It's number 1. Just thought I'd share the different results I got. - Ryan McClure Music Education Major, Shepherd University Luna Music Engraving www.lunamusicengraving.com -- View this message in context: http://lilypond.1069038.n5.nabble.com/LilyPond-Website-Work-was-A-thought-on-Windows-Experience-tp155110p155236.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
From: Ryan McClure ryanmichaelmccl...@gmail.com Sent: Friday, December 06, 2013 6:59 PM I just did a Google search on a computer that I've never used/logged into before. My account was fresh, and I did these searches without any previous history affecting my results: Music notation software Lilypond came in at 25. Free music notation software It came in at 11. Free music typesetting software It was 7. Music typesetting software It's number 1. Just thought I'd share the different results I got. Ah yes, forgot, I was using google.co.uk when I did that search. Phil. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
From: Ryan McClure ryanmichaelmccl...@gmail.com Sent: Friday, December 06, 2013 6:59 PM I just did a Google search on a computer that I've never used/logged into before. My account was fresh, and I did these searches without any previous history affecting my results: Music notation software Lilypond came in at 25. Free music notation software It came in at 11. Free music typesetting software It was 7. Music typesetting software It's number 1. Just thought I'd share the different results I got. Ah yes, forgot, I was using google.co.uk when I did that search. Phil. And a correction to my own search (google.co.uk)... free music notation software 9. lilypond.org I thought it was a bit strange that I couldn't find lilypond after 20 pages! Phil. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
Urs, 2013/12/6 David Kastrup d...@gnu.org: Urs Liska m...@ursliska.de writes: Am 06.12.2013 14:12, schrieb Federico Bruni: These problems should be recorded in our tracker. So far I've seen 2 issues/feature requests: 1. improve SEO 2. associate a different color scheme to each manual I think although not explicitly stated as a feature request the discussion surely yields 3. Clarify first steps/new user experience. I don't think that this is the same topic. The listed requests are about the web site representation and possible restructuring, but you talk about content details. They may be worth amending, but that's not the Website Work that Carl is thinking about doing. It has nothing to do with website programming. David is right, this is a different kind of task - not technical, but creative. And i think it's worth doing; personally i agree with your suggestions. Since this is separate from Carl's work, i think you could start right now and work in parallel to him. For starters, create a patch with a set of most obvious changes - it should go through easily, and i'll gladly review it! best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond Website Work
Am 06.12.2013 21:26, schrieb Janek Warchoł: Urs, 2013/12/6 David Kastrup d...@gnu.org: Urs Liska m...@ursliska.de writes: I think although not explicitly stated as a feature request the discussion surely yields 3. Clarify first steps/new user experience. I don't think that this is the same topic. The listed requests are about the web site representation and possible restructuring, but you talk about content details. They may be worth amending, but that's not the Website Work that Carl is thinking about doing. It has nothing to do with website programming. David is right, this is a different kind of task - not technical, but creative. And i think it's worth doing; personally i agree with your suggestions. Since this is separate from Carl's work, i think you could start right now and work in parallel to him. For starters, create a patch with a set of most obvious changes - it should go through easily, and i'll gladly review it! OK, I'll review the entry path again - more closely and concretely - and will think about an outline. Once that's finished I'll decide whether to create a patch directly or put that outline up for discussion first. Urs best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
LilyPond Website Work (was: A thought on Windows Experience)
Branching this discussion into its own topic On Thu, Dec 5, 2013 at 11:25 AM, Phil Burfitt phil.burf...@talktalk.netwrote: Tim McNamara wrote: If you think that Lilypond's web page needs a facelift, then volunteer to roll up your sleeves and help change it... Werner Lemberg wrote: Do you want to work on that? We don't have a specialist who really likes to dive into the nifty HTML and Java issues while creating the contents via the texinfo format so that the PDF stays in sync with the HTML and info output. Tim and Werner, I would love to, and have considered a few times in the past. Unfortunately I do not have the time, have no experience of texinfo, and would probably have to ditch it within the coming year due to future plans anyway. I don't know how the current system is setup, but I don't see the need for nifty HTML. A separation of content and presentation, with clean, simple, hand coded (s)html pages (as noted by others...html authoring tools clutter the code - usually with info needed by the authoring tool itself) . Extensive use of divs, the usual webpage furniture where needed (menus, crumblines, buttons, etc), a few graphics, style sheets, and little else. Definitely no client-side scripting, and content for dynamic pages (and static pages if you want) provided by server-side includes. It seems child's play to me, but David's comments leave me wondering how entangled the current setup may be. Having dived into the git repo and page source a little, here is what I see as the road map to improving the look of the LilyPond website, with an eye toward getting the most benefit the fastest. 1) Review the CSS of both the website and the documentation. These are simply CSS files that don't need any compiling or reconfiguring. The eyesore for me is the documentation, and it would be nice to start to move the two into more of a seamless experience (where there's not an obvious change in the look beyond the documentation being documentation with a side frame for navigation. 2) Look at updating the images. One of the things that has come to mind on this point is updating the LilyPond icon/logo. If we want to compare looks to other software packages, take a look at those in comparison (or in comparison to about 75% or more of the well-known commercial programs overall. I'm currently working on a logo design using Inkscape/SVG as the source, which will have the advantage of being text-based and thus well-integrated into git (if, for whatever reason, we would want to think about changing it in the future. I realize that change would impact potentially the build process if there's any icon creation going on. 3) Consider different structural issues. This, I think, is where we really start to get into questions about texinfo and how that is compiled into the static web pages. Such changes may require us going back to #1 above, but I think a lot of the changes at this level may or may not have a tangible benefit in marketing LilyPond. The real impact is going to be on #1 and to an extent, #2, which provides the user the initial impression of how modern or friendly LilyPond is. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
Hi, 2013/12/5 Carl Peterson carlopeter...@gmail.com: Having dived into the git repo and page source a little, here is what I see as the road map to improving the look of the LilyPond website, with an eye toward getting the most benefit the fastest. [...] I have no expertise in these areas, so i cannot comment on the technical side. But i can provide feedback and testing - just ask! best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
On 12/5/13 9:43 AM, Carl Peterson carlopeter...@gmail.com wrote: 1) Review the CSS of both the website and the documentation. These are simply CSS files that don't need any compiling or reconfiguring. The eyesore for me is the documentation, and it would be nice to start to move the two into more of a seamless experience (where there's not an obvious change in the look beyond the documentation being documentation with a side frame for navigation. Personally, I prefer the obvious change in look, because I like to know when I'm in the documentation. But that's just *my* opinion; others may agree with you. Thanks, Carl S. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPond Website Work (was: A thought on Windows Experience)
On Thu, Dec 5, 2013 at 8:13 PM, Carl Sorensen c_soren...@byu.edu wrote: On 12/5/13 9:43 AM, Carl Peterson carlopeter...@gmail.com wrote: 1) Review the CSS of both the website and the documentation. These are simply CSS files that don't need any compiling or reconfiguring. The eyesore for me is the documentation, and it would be nice to start to move the two into more of a seamless experience (where there's not an obvious change in the look beyond the documentation being documentation with a side frame for navigation. Personally, I prefer the obvious change in look, because I like to know when I'm in the documentation. But that's just *my* opinion; others may agree with you. Thanks, Carl S. Having worked for two corporations that have fairly extensive (and stringent) visual identity and branding guidelines (colors, typeface, formatting, etc.), I've learned that there are ways to make an obvious change between two things while still making them look like they go together. At a minimum, unless we do a complete overhaul of our documentation system, the navigation sidebar is going to be an obvious indication that we've gone to another system. There are other things, such as header bars (as we have), that by their presence will indicate a different system, but the basic design can be similar or the same. That being said, you may be right, and perhaps we need some additional distinction between the two. *But,* I do feel like the stylesheet on the documentation needs to be reviewed and updated, regardless. Cheers, Carl P. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
