Re: Fwd: Re: Website improvements, part 1

[Urs Liska]

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 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.

Do I see it right that I should definitely make such a patch only when 
no other pending patches still point to "Easier editing"?

> > - 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.

And:
- remove GSoC page (although that's in the "Community" section and could 
therefore be postponed).
- Update Manuals->Web page as previously discussed.

Urs
> - Graham