[LV2] LV2 site inputs

[David Robillard]

On 2014-12-04 13:10, Spencer Jackson wrote:
> Nice work! I like having some buttons and more content below the images
> because otherwise you read down the page and feel there is nowhere to go.
> There is a minor typo in the top bar "geting" -> "getting" but I really
> like the look. Where would the list of projects using lv2 fit in? Under
> getting started?

I see the opposite problem: if there's a full page of images, the actual
content will often get pushed right off the end of the screen.  This is
a very bad thing.

I agree the current site isn't particularly well balanced, though.  A
fixed size slider thing like Bruno suggests would probably help with
this, we get constrained size taken on the page, but without having to
have uniform screenshot sizes which is essentially impossible.  I'm
doubt full width is a good idea in reality though, on 2/4 of my screens
that will look ridiculous, just in a different way.

> I'm a little more concerned about the news section though. Its a good idea
> IF we can keep a reasonably frequent feed going. When I find a site with
> the latest news older than a few months I immediately wonder if the project
> is up to date and actively maintained. I think lv2 will slowly mature and
> need updating less and less often, generating less and less news. Anyone
> have thoughts on this?

Releases would be the obvious thing.  I don't know if any actual
"articles" or anything of the sort will ever show up, but I do post
things occasionally on my own blog that would fit.  Others writing stuff
would be nice, so setting up the page to have a slot for it might
encourage this.

Releases are currently pegged at around a few a year, and will probably
remain so indefinitely, though right now this greatly depends on my life
situation, so who knows...

Design wise, if we have news of whatever sort, I think needs to be on a
separate page.  Pelican is (at least partially) a blog platform, and has
nice support for this with RSS feeds and everything, but you can't cram
a feed and a static page into the same thing AFAIK.  It may be possible,
but having a news feed page is built-in and requires basically zero
effort, so the question becomes: is it worth it?  Maybe, but probably
not, IMO.

Even if you could, we can't/shouldn't do two columns, which leads me to
the following:

I think we're falling into the pit where most photostop/etc-driven web
design goes, from which it is difficult to see several realities about
real web pages and their deployment (this is not a criticism of the/any
design, it's just what happens).  To that end, here are The Rules of the
site:

* It must appear nicely on an extreme range of display sizes and DPIs,
from tiny cell phone displays, to HiDpi laptop panels, to 30" screens.

* Must appear nicely regardless of user's font size (accessibility).

* Consequently, the content must be one column of text (constrained to
some reasonable maximum width *in ems*).  Our content (simple pages in
Markdown) happens to be exactly that anyway.  Also an accessibility
issue, and makes the pages a pleasure to work on in general.

* No fixed pixel sized anything, period, except screenshots or other
images which are inherently so.

* Pure CSS is preferable to images in general, for the same reasons.

* Consistency across all four "sub-sites" (Pelican site, cgit, spec
docs, Doxygen docs)

All of these things are currently true (the last only in git), as far as
I can tell / to the best of my ability / etc.  Improvements are more
than welcome, but I will not be moving backwards on any of the above
requirements.

The design goals are (basically as Harry already said), in order of
importance:

1) Make it clear where the information people need is located, and as
efficient as possible (e.g. one click) to get there.

2) Make that information as simple, clear, and straightforward as possible.

3) Look pretty

1 and 2 are crucially important.  Related design issues: what goes in
the top bar, what's a link on the main page, what pages exist for what
purpose, what information do most people actually want to get at, etc.

3 is important, and I appreciate all the interest in it, but prettiness
must be maximized ideally *in support of* the other things, or at least
*not the exclusion of*, but very certainly not *to the detriment of*.

As an aside, everyone is purely focused on the shiny whiz-bang front
page, which is something of a special case, and not whatsoever on the
rest of the site, which is very important (moreso, really, the main
page's only goal is to point people to the appropriate bit while looking
shiny doing it).  Aesthetically, I think elegant simplicity is the best
goal.  If there's anything LV2 as a project needs to drive towards, it's
simplicity, simplicity, simplicity.  Aside from the front page which is
perhaps a special case, the site is text meant to be read.  The goal of
"pretty" there is a bit different: not heavy duty gradients and pixmaps
and lens flares of shiny "pitch" sites, but layout, good use of space,
clear structure, and so on.  Beautiful in the sense that a well typeset
book is beautiful.  Use and spacing of lists, what does inset code look
like, structure of documentation, indices, paragraph and title
separation, all very important stuff for making a nice piece of text to
read.  Also conveniently timeless and doesn't become dated.

I prefer this aesthetic universally, but if everyone else wants to spend
months on the shiny whiz-bang front page, have fun.  I will apply
whatever is generally agreed upon that does not violate the above
guidelines.  (My personal time is much better spent on a vast number of
other things nobody else is about to do, in case that's not obvious, so
I won't be implementing it myself)

This all sounds critical of the various inputs so far, but that is not
my intent.  I just realize I haven't made clear what I feel are the
goals of the site, and one cannot design without goals.  So there they are.

Cheers,

-- 
dr


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20141204/fb320738/attachment-0001.pgp>