Branching this discussion into its own topic On Thu, Dec 5, 2013 at 11:25 AM, Phil Burfitt <phil.burf...@talktalk.net>wrote:
> > 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
