Re: Fwd: Re: Website improvements, part 1
Am 16.12.2013 04:35, schrieb David Kastrup: I'd lean towards applications. Basically, it seems to be LilyPond as a building block but that's too long for a tab name. That's the problem: All suggestions that hit the spot need phrases and not single words. But IISC Applications it the term suggested most often. Thank you all for your constructive feedback. I will come back to it, but today I'm very busy with urgent non-musical issues. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Website improvements, part 1
Am 16.12.2013 04:15, schrieb Graham Percival: On Fri, Dec 13, 2013 at 01:57:23PM +0100, Urs Liska wrote: Am 12.12.2013 04:19, schrieb Graham Percival: ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? If this was aimed at programmers, I'd be tempted to call it Integration or Library, but those would not be clear to 95%+ of people reading the introduction. Hmm... I have a slight preference for applications rather than appliances; as a native speaker, I think appliances as being things like the fridges, ovens, or washing machines. As said in another reply I have the impression that Applications is what the majority of commenters would suggest. Although I've got two votes for Other uses, which might also be quite telling when seen as a menu item. IMO examples should remain part of that. Any more opinions on that? My reasoning was: - I think Features-Background-Freedom and then How LilyPond works is a good reading path - Examples is similar to a Screenshots menu item in many websites and can be somewhat taken out of that intitial reading path Yes and no... I totally agree that Examples is similar to screenshots, but when we're talking about music engraving, the quality of engraving (and flexibility / range of supported notation) is an essential feature. The only reason I didn't put examples and features together was that I wanted to have a tab called examples for additional visibility; some readers might not realize that features included examples if I put them together. I mean, if you're talking about why use lilypond?, then IMO the examples are the most important part. Freedom matters to some people but not others, and IMO the background is almost completely irrelevant. OK, that makes sense. Thank you for being more elaborate. If anything, I think that the web frontends should get their own tab. You mean the box from Editing should be raised to its own page, next to Editing? Yes. OK The general design of the website is to go top-left, top-right, bottom-left, bottom-right. I'm not certain this is an important distinction, but it's worth considering. OK, I considered it by clicking through the complete website (except the docs of course) and saw that there isn't any single comparable case. Usually when we have two boxes side by side they are followed by a column-center box, so the flow is clear. True. Could we retain the flow in a similar way? Do we need 4 divs, or could we still only have 3? I'll look into that. Probably it's possible to do with three. or maybe 1-2-1-1 which would make the flow easier to follow. So what to do with it? Semantically it would be less ambiguous to use only one column for the Introduction page. But that wouldn't look nice because the items are so short. I could accept changing this order (i.e. exchange the boxes right-top and bottom-left), but I wouldn't consider it necessary - the ambiguity should be suitable for that page. I'm still not wild about this optional flow. The original pages were aimed at: - info 1. Decided you want lilypond? goto text input. Not decided go next. - info 2. Decided you want lilypond? goto text input. Not decided go next. - info 3. Decided you want lilypond? goto text input. Not decided go next. - info 4. ... etc. The whole goal is to funnel people towards text input so they get the warnings about lilypond. Either people aren't reaching text input, or the warnings on that page aren't sufficiently clear. I think that's a more clear flow than the proposed change. Hm, I'll have to think about this once more. Now I see your idea. But my impression is that this doesn't make Text input the ultimate goal where the reader reaches enlightenment, but instead rather makes it less prominent. I mean, from its positioning in the menu it comes even after Productions and Reviews - nobody would expect crucial information there, it's rather the place for the legalese stuff or a contact form... Well, if the narrative flow would be kept, there are _at least_ two things I'd definitely change: - Make it more explicit that the Introduction is a Tour intended to be followed. - Reword the link to Text input. Currently this is somewhat misunderstandable. If I have You want LilyPond, then you can now I'd expect this to be download it. But we want to say: download it, but _before read Text input_. The incentive for reviewing of the website structure was (on lilypond-user) that too many people don't realize the basics of the compiled approach when visiting the website. See other
Re: Fwd: Re: Website improvements, part 1
Urs Liska u...@openlilylib.org writes: Am 16.12.2013 04:15, schrieb Graham Percival: On Fri, Dec 13, 2013 at 01:57:23PM +0100, Urs Liska wrote: Am 12.12.2013 04:19, schrieb Graham Percival: ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? If this was aimed at programmers, I'd be tempted to call it Integration or Library, but those would not be clear to 95%+ of people reading the introduction. Hmm... I have a slight preference for applications rather than appliances; as a native speaker, I think appliances as being things like the fridges, ovens, or washing machines. As said in another reply I have the impression that Applications is what the majority of commenters would suggest. Although I've got two votes for Other uses, which might also be quite telling when seen as a menu item. It's more like Internal Use. Possibly Integration or Embedding. I'm just floating a few words, it's not like any of them has quite the right ring to me, either. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Website improvements, part 1
Am 16.12.2013 11:11, schrieb David Kastrup: As said in another reply I have the impression that Applications is what the majority of commenters would suggest. Although I've got two votes for Other uses, which might also be quite telling when seen as a menu item. It's more like Internal Use. Possibly Integration or Embedding. I'm just floating a few words, it's not like any of them has quite the right ring to me, either. Embedding LilyPond? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Website improvements, part 1
On Fri, Dec 13, 2013 at 01:57:23PM +0100, Urs Liska wrote: Am 12.12.2013 04:19, schrieb Graham Percival: ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? If this was aimed at programmers, I'd be tempted to call it Integration or Library, but those would not be clear to 95%+ of people reading the introduction. Hmm... I have a slight preference for applications rather than appliances; as a native speaker, I think appliances as being things like the fridges, ovens, or washing machines. IMO examples should remain part of that. Any more opinions on that? My reasoning was: - I think Features-Background-Freedom and then How LilyPond works is a good reading path - Examples is similar to a Screenshots menu item in many websites and can be somewhat taken out of that intitial reading path Yes and no... I totally agree that Examples is similar to screenshots, but when we're talking about music engraving, the quality of engraving (and flexibility / range of supported notation) is an essential feature. The only reason I didn't put examples and features together was that I wanted to have a tab called examples for additional visibility; some readers might not realize that features included examples if I put them together. I mean, if you're talking about why use lilypond?, then IMO the examples are the most important part. Freedom matters to some people but not others, and IMO the background is almost completely irrelevant. If anything, I think that the web frontends should get their own tab. You mean the box from Editing should be raised to its own page, next to Editing? Yes. The general design of the website is to go top-left, top-right, bottom-left, bottom-right. I'm not certain this is an important distinction, but it's worth considering. OK, I considered it by clicking through the complete website (except the docs of course) and saw that there isn't any single comparable case. Usually when we have two boxes side by side they are followed by a column-center box, so the flow is clear. True. Could we retain the flow in a similar way? Do we need 4 divs, or could we still only have 3? So what to do with it? Semantically it would be less ambiguous to use only one column for the Introduction page. But that wouldn't look nice because the items are so short. I could accept changing this order (i.e. exchange the boxes right-top and bottom-left), but I wouldn't consider it necessary - the ambiguity should be suitable for that page. I'm still not wild about this optional flow. The original pages were aimed at: - info 1. Decided you want lilypond? goto text input. Not decided go next. - info 2. Decided you want lilypond? goto text input. Not decided go next. - info 3. Decided you want lilypond? goto text input. Not decided go next. - info 4. ... etc. The whole goal is to funnel people towards text input so they get the warnings about lilypond. Either people aren't reaching text input, or the warnings on that page aren't sufficiently clear. I think that's a more clear flow than the proposed change. The incentive for reviewing of the website structure was (on lilypond-user) that too many people don't realize the basics of the compiled approach when visiting the website. See other thread for clarifying text input. More involved changes that I could nevertheless put up for review? - Rename Easier Editing to Editing (does this affect translation more than other changes?) Probably, but that's why it's even more important to present that as an independent change. - Updating the Editing page (split in two parts: reorganisation of items / rewording) - Rewrite of the Features page I'd include adding a new page for web apps in the list of small, independent patches that should go forward. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fwd: Re: Website improvements, part 1
Graham Percival gra...@percival-music.ca writes: On Fri, Dec 13, 2013 at 01:57:23PM +0100, Urs Liska wrote: Am 12.12.2013 04:19, schrieb Graham Percival: ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? If this was aimed at programmers, I'd be tempted to call it Integration or Library, but those would not be clear to 95%+ of people reading the introduction. Hmm... I have a slight preference for applications rather than appliances; as a native speaker, I think appliances as being things like the fridges, ovens, or washing machines. Well, the proposal was literally applicances which is not a word. I'd lean towards applications. Basically, it seems to be LilyPond as a building block but that's too long for a tab name. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website improvements, part 1
Am 12.12.2013 04:19, schrieb Graham Percival: On Wed, Dec 11, 2013 at 02:21:28PM +0100, Urs Liska wrote: - I changed Easier editing to Editing. ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? - I organized the entry scenario (= introduction.html) according to three questions - Why should I consider LilyPond? IMO examples should remain part of that. Any more opinions on that? My reasoning was: - I think Features-Background-Freedom and then How LilyPond works is a good reading path - Examples is similar to a Screenshots menu item in many websites and can be somewhat taken out of that intitial reading path - I added the link to Examples to the Where now? box on Features. However, now I see that I would revert making Background link directly to the Essay manual because that would take the reader out of the reading path. (and my updated text on Background makes it easier to understand) - Does it really work/what's the real-world use? I'd be fine with calling that box LilyPond in the real world, although I'm not certain if the applicances should be in this category. I mean, some of them make sense (like wikipedia), but others seem like toy examples. That's probably right, but we should hope to get more entries to that page in the future. And even toy examples give an impression of the diversity of things you can do with LilyPond. We've already covered serious use in Productions. I have to say, the Appliances are more questionable after renaming the box as you suggest ;-) If anything, I think that the web frontends should get their own tab. You mean the box from Editing should be raised to its own page, next to Editing? This is reflected in the layout of the boxes on introduction.html while it's irrelevant in which direction the user proceeds from the Why box At the moment, the order seems to go top-left, bottom-left, top-right, bottom-right. It is, although it was on purpose that after the first box you can actually go right _or_ down. The general design of the website is to go top-left, top-right, bottom-left, bottom-right. I'm not certain this is an important distinction, but it's worth considering. OK, I considered it by clicking through the complete website (except the docs of course) and saw that there isn't any single comparable case. Usually when we have two boxes side by side they are followed by a column-center box, so the flow is clear. The only exception is on the Download subpages: - on the Mac and Windows pages we have two short boxes left and one long box right. But they're not clearly defining a reading path but rather an alternative - on the Unix page we also have two boxes left and one box right, but it's clear that it's going top-left, bottom-left, right. So what to do with it? Semantically it would be less ambiguous to use only one column for the Introduction page. But that wouldn't look nice because the items are so short. I could accept changing this order (i.e. exchange the boxes right-top and bottom-left), but I wouldn't consider it necessary - the ambiguity should be suitable for that page. Any more opinions? However, I still think that text input and editing should be the final part of the introduction. Please specify why you think so. The incentive for reviewing of the website structure was (on lilypond-user) that too many people don't realize the basics of the compiled approach when visiting the website. Which causes too many people to get stuck when they're not able to open LilyPond. My goal was to strenghten the conceptual side in the default reading path by leading to these core concepts earlier. As mentioned above I consider Examples, Productions and Appliances more like an optional path. - I think it would be good to add something about version control on the Text input page, but that's something I wouldn't want to do without prior discussion. I disagree. The purpose of text input is to make potential users realize that yes, we use text, but no, it's not too complicated. Version control is a complicated concept for non-programmers which would dilute the previous message. You already mentioned version control on the Features page, which should be sufficient. Accepted. This is why I asked first in that case ;-) - I think the @contactUsAbout macro should be reconsidered. I agree, you made good points here. Please note that *this* is the kind of change that can be done immediately, submitted for review, etc. It doesn't
Fwd: Re: Website improvements, part 1
Am 12.12.2013 11:00, schrieb Urs Liska: Then I should base a patch on current master, upload it and - assuming it will be accepted - mail the patch to someone (?) for pushing it? OK, I've now uploaded my first two patches (one about the content and one addressing in the CG a problem I encountered for the first). I'll see how this works out and decide how to proceed. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website improvements, part 1
Urs Liska wrote Am 12.12.2013 04:19, schrieb Graham Percival: On Wed, Dec 11, 2013 at 02:21:28PM +0100, Urs Liska wrote: - I changed Easier editing to Editing. ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). Just a bunch of ideas: We're talking about - Applications of LilyPond - Use of LilyPond in different contexts - Abusing LiylPond - integrating LilyPond in other tools - making LilyPond part of something else - using LilyPond as an engine for other tools Does this trigger any ideas for a menu/page title with anybody? What about just Other uses ? That's broad enough to cover anything that one might want to put there in the future. (It's the best thing I've been able to come up with.) -Paul -- View this message in context: http://lilypond.1069038.n5.nabble.com/Website-improvements-part-1-tp155589p155659.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Website improvements, part 1
Hi all, [I have sent a message a few hours ago, but from a different email account. If this first email should go through nevertheless, the email you are reading now is the only relevant version.] as should be known by now I'm currently reviewing the content of lilypond.org to make it more accessible to new users. Originally I intended to clarify the command-line-enhanced-editor issue to avoid the double-click-on-lilypond.exe-doesn't-open-program misconception, but it seems to be necessary to do quite some more restructuring of the reading trail. As one change leads to another this would easily lead to a complete rewrite of the website. And as I don't want to do that and confront you with a finished suggestion it's high time now to discuss what I've done so far. This email has three parts: a) my current result suggested for an informal review, b) (technical) detail questions about them and c) questions about what still has to be done. I have discussed with Carl (Peterson) that it would be good to proceed with the following steps: - get the proposed _content_ changes into a shape for a formal review. (Do this informally and incrementally so we'll have only one formal review in the end) - Once that's clear Carl will work on a new appearance, taking into account if the content would require structural changes - While he's working on that translators can try to update the website translations - Finally everything should be released in one go. ### a) I've reviewed the Introduction section and the Download entry page. I have always tried to keep as much in its current state. That is either leave it alone completely or relocate a subsection without changing it. But of course this wasn't always possible. So I would say: If I have touched any existing material I'm sure it had to be touched. But what I've done with it and what I've added may be influenced by my personal view on LilyPond. A good part of what I'm presenting today has already been commented by Janek, so it's not _completely_ my homegrown stuff. If you look at my suggestions, please try to see it as it is now and try not to consider what I changed. I tried very hard to determine the type, amount and order of information someone would need who doesn't know about LilyPond, text input, a compiled system architecture etc., so please try also to ignore as much of your existing knowledge about these topics. You can see the result of my work so far at http://openlilylib.org/lilyweb/introduction.html I have uploaded all pages below Introduction plus download.html. They are displayed with the current CSS but without images. The links between the uploaded pages work as expected, while everything else obviously goes 404. The commits leading to this are here: https://github.com/lilypond/lilypond/tree/urs/restructure-web. (This branch is subject to be rebased at any point until further notice) I have a few comments on my changes. Maybe you should first browse my pages and then read the comments. - I changed Easier editing to Editing. Actually this is what we're talking about. While technically editing means any editor and easier editing means dedicated tools this isn't a relevant distinction for the average (and particularly a new) user. What we want and what seems to have been the consensus on lilypond-user is to make clear that LilyPond itself isn't an editing environment but that the usual way (and the one that should be recommended on lilypond.org) to work with it is to install LilyPond itself and a dedicated tool in addition. Preferrably installing the tool which should in turn take care of installing LilyPond. - I organized the entry scenario (= introduction.html) according to three questions (Janek's suggestion): - Why should I consider LilyPond? - How does it work? - Does it really work/what's the real-world use? This is reflected in the layout of the boxes on introduction.html while it's irrelevant in which direction the user proceeds from the Why box - I sorted the page order (menu entries) according to that structure - I've adapted the Where now boxes to reflect this order too, while at the same time offering a slightly more flexible reading path - One page I restructured in particular is the Features page which I actually found quite unstructured. But also here I tried to keep as much in its original state as possible. - I added a new page for the What people did with LilyPond gallery. Lacking a better name I labeled it Appliances, please suggest better names. Actually it's about applications of LilyPond for other uses, but Applications would certainly raise wrong expectations. ### b) - I have added a few @anchor-s, particularly on the editing page. Adding an anchor to a @subheading creates an empty paragraph (as can be seen in the current draft), but linking to the implicit anchor that @subheading creates doesn't work and
Re: Website improvements, part 1
Urs, On 11/12/13 14:14, David Kastrup wrote: Urs Liska u...@openlilylib.org writes: I have discussed with Carl (Peterson) that it would be good to proceed with the following steps: - get the proposed _content_ changes into a shape for a formal review. (Do this informally and incrementally so we'll have only one formal review in the end) - Once that's clear Carl will work on a new appearance, taking into account if the content would require structural changes - While he's working on that translators can try to update the website translations The last point won't work: you rather need to update the structure of the translations yourself so that the result passes compilation and is valid HTML. The problem we have is that translators work on a single branch, and that branch currently is a translation of the stable/2.18 branch. It does not make sense to change this before the release, and we'll likely be locked until 2.18.1 as well. In addition, only some translations are actually reasonably up-to-date, so even without this impediment, you need to get the structure fixed in a time frame independent from the ongoing translations. I am starting some patches for Web part of the 'doc' via the tracker and these are going to be against staging/master. So it would be helpful for you I think if you did just base all your work on 2.18 as you may be having to rebase all the time or get frustrated as the staging tree moves along. At least stable/2.18 is going to be reasonably static. Just my 2 cents worth based on experience like this. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website improvements, part 1
Am 11.12.2013 15:31, schrieb James: Urs, On 11/12/13 14:14, David Kastrup wrote: Urs Liska u...@openlilylib.org writes: I have discussed with Carl (Peterson) that it would be good to proceed with the following steps: - get the proposed _content_ changes into a shape for a formal review. (Do this informally and incrementally so we'll have only one formal review in the end) - Once that's clear Carl will work on a new appearance, taking into account if the content would require structural changes - While he's working on that translators can try to update the website translations The last point won't work: you rather need to update the structure of the translations yourself so that the result passes compilation and is valid HTML. The problem we have is that translators work on a single branch, and that branch currently is a translation of the stable/2.18 branch. It does not make sense to change this before the release, and we'll likely be locked until 2.18.1 as well. In addition, only some translations are actually reasonably up-to-date, so even without this impediment, you need to get the structure fixed in a time frame independent from the ongoing translations. I am starting some patches for Web part of the 'doc' via the tracker and these are going to be against staging/master. So it would be helpful for you I think if you did just base all your work on 2.18 as you may be having to rebase all the time or get frustrated as the staging tree moves along. At least stable/2.18 is going to be reasonably static. Just my 2 cents worth based on experience like this. James OK, this means: - I rebase my current branch on stable/2.18 - when I'm finished (including informal reviews along the way) I rebase again if 2.18 should have moved in the meantime ? What to do then? What are you working on? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website improvements, part 1
Urs, On 11/12/13 14:36, Urs Liska wrote: Am 11.12.2013 15:31, schrieb James: Urs, On 11/12/13 14:14, David Kastrup wrote: Urs Liska u...@openlilylib.org writes: I have discussed with Carl (Peterson) that it would be good to proceed with the following steps: - get the proposed _content_ changes into a shape for a formal review. (Do this informally and incrementally so we'll have only one formal review in the end) - Once that's clear Carl will work on a new appearance, taking into account if the content would require structural changes - While he's working on that translators can try to update the website translations The last point won't work: you rather need to update the structure of the translations yourself so that the result passes compilation and is valid HTML. The problem we have is that translators work on a single branch, and that branch currently is a translation of the stable/2.18 branch. It does not make sense to change this before the release, and we'll likely be locked until 2.18.1 as well. In addition, only some translations are actually reasonably up-to-date, so even without this impediment, you need to get the structure fixed in a time frame independent from the ongoing translations. I am starting some patches for Web part of the 'doc' via the tracker and these are going to be against staging/master. So it would be helpful for you I think if you did just base all your work on 2.18 as you may be having to rebase all the time or get frustrated as the staging tree moves along. At least stable/2.18 is going to be reasonably static. Just my 2 cents worth based on experience like this. James OK, this means: - I rebase my current branch on stable/2.18 - when I'm finished (including informal reviews along the way) I rebase again if 2.18 should have moved in the meantime ? What to do then? What are you working on? There are a few Web issues on the tracker that are adding links for user's own work (I.e. my work is all TexInfo based, none of the CSS or SOE stuff) such as what people have done with LilyPond, Video Tutorial links and the like. This will all, once approved, go into staging/master and then David can choose (or not) to cherry pick it for the Website part of 2.18. I somehow thing that once you are done your 'patch' will be large and need some significant reviewing whereas I am doing 'itty bitty' texinfo additions. Such as: https://codereview.appspot.com/40570043 James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website improvements, part 1
Am 11.12.2013 15:59, schrieb James: Urs, On 11/12/13 14:36, Urs Liska wrote: Am 11.12.2013 15:31, schrieb James: Urs, On 11/12/13 14:14, David Kastrup wrote: Urs Liska u...@openlilylib.org writes: I have discussed with Carl (Peterson) that it would be good to proceed with the following steps: - get the proposed _content_ changes into a shape for a formal review. (Do this informally and incrementally so we'll have only one formal review in the end) - Once that's clear Carl will work on a new appearance, taking into account if the content would require structural changes - While he's working on that translators can try to update the website translations The last point won't work: you rather need to update the structure of the translations yourself so that the result passes compilation and is valid HTML. The problem we have is that translators work on a single branch, and that branch currently is a translation of the stable/2.18 branch. It does not make sense to change this before the release, and we'll likely be locked until 2.18.1 as well. In addition, only some translations are actually reasonably up-to-date, so even without this impediment, you need to get the structure fixed in a time frame independent from the ongoing translations. I am starting some patches for Web part of the 'doc' via the tracker and these are going to be against staging/master. So it would be helpful for you I think if you did just base all your work on 2.18 as you may be having to rebase all the time or get frustrated as the staging tree moves along. At least stable/2.18 is going to be reasonably static. Just my 2 cents worth based on experience like this. James OK, this means: - I rebase my current branch on stable/2.18 - when I'm finished (including informal reviews along the way) I rebase again if 2.18 should have moved in the meantime ? What to do then? What are you working on? There are a few Web issues on the tracker that are adding links for user's own work (I.e. my work is all TexInfo based, none of the CSS or SOE stuff) such as what people have done with LilyPond, Video Tutorial links and the like. This will all, once approved, go into staging/master and then David can choose (or not) to cherry pick it for the Website part of 2.18. I somehow thing that once you are done your 'patch' will be large and need some significant reviewing whereas I am doing 'itty bitty' texinfo additions. Such as: https://codereview.appspot.com/40570043 James OK, I see, but that's actually affecting my work, i.e. you're touching the same files and content as I do. Of course what you say is right, and you should incorporate yours first. But of course it will cause issues for me because I modified the stuff that you are working on top of. See in particular https://github.com/lilypond/lilypond/commit/dce9c0e484779863d7fbf980b80e079e90acf55e regarding the patch in your link. Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website improvements, part 1
Am 11.12.2013 15:14, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: I have discussed with Carl (Peterson) that it would be good to proceed with the following steps: - get the proposed _content_ changes into a shape for a formal review. (Do this informally and incrementally so we'll have only one formal review in the end) - Once that's clear Carl will work on a new appearance, taking into account if the content would require structural changes - While he's working on that translators can try to update the website translations The last point won't work: you rather need to update the structure of the translations yourself so that the result passes compilation and is valid HTML. Sorry, I don't really understand what this means. Please be slightly more verbose. I see the issue of branches that James was talking about, but I don't think that's what you mean. Considering the strucutre of the translations: Either I didn't make myself clear or I don't understand something. All i have done so far is editing the .itexi files in Documentation/web. when I 'make website' I see the english site as I modified it and all the other languase (to the extent I can check them) in their old form. But make doesn't complain, and they are correctly displayed, although with their old content of course. When changing the page order I rearranged the @nodes in the .itexi files and switched the corresponding lines in the @menu section. This is of course not represented in the translations. So what should I do now? Proceed until I'm (we're) finished and then rebase to some-branch before uploading for review? Do _I_ have to propagate these rearrangements to the translations at that point? Urs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website improvements, part 1
On Wed, Dec 11, 2013 at 02:21:28PM +0100, Urs Liska wrote: - I changed Easier editing to Editing. ok. I also like the applicances tab, although I agree with you that the name might be ideal (but I also can't think of a better name right now). - I organized the entry scenario (= introduction.html) according to three questions - Why should I consider LilyPond? IMO examples should remain part of that. - Does it really work/what's the real-world use? I'd be fine with calling that box LilyPond in the real world, although I'm not certain if the applicances should be in this category. I mean, some of them make sense (like wikipedia), but others seem like toy examples. If anything, I think that the web frontends should get their own tab. This is reflected in the layout of the boxes on introduction.html while it's irrelevant in which direction the user proceeds from the Why box At the moment, the order seems to go top-left, bottom-left, top-right, bottom-right. The general design of the website is to go top-left, top-right, bottom-left, bottom-right. I'm not certain this is an important distinction, but it's worth considering. However, I still think that text input and editing should be the final part of the introduction. - I think it would be good to add something about version control on the Text input page, but that's something I wouldn't want to do without prior discussion. I disagree. The purpose of text input is to make potential users realize that yes, we use text, but no, it's not too complicated. Version control is a complicated concept for non-programmers which would dilute the previous message. You already mentioned version control on the Features page, which should be sufficient. - I think the @contactUsAbout macro should be reconsidered. I agree, you made good points here. Please note that *this* is the kind of change that can be done immediately, submitted for review, etc. It doesn't need to wait for James to finish his changes or 2.18 to be released. I would *heavily* encourage you to submit small improvements like this soon, instead of combining them in a large reorganization that creates havoc for translators. Apart from the technical impact on the doc system, making small changes like this reassure developers that you're serious and that you know how the system works. - The structure of the Community section is, ehm, wild. I think it would be good to have an additional navigational layer. But before thinking about a structure I'd like to know if this would be accepted. Probably not. There's @chapters and @sections; having a bunch of @subsections for one chapter is a bit weird. I agree that Community is a bit wild; can you think of a division that would split it into two chapters? - I have one question about the structure of Manuals: What the hell is this Web menu item for? The website. It's created as a pdf and info. One of the very early goals of the doc system is that all the information should be present via only info or pdfs (i.e. without an internet connection). - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
