lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Re: Website improvements, part 1


From: Graham Percival
Subject: Re: Fwd: Re: Website improvements, part 1
Date: Mon, 16 Dec 2013 11:15:54 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]