Re: Blends pages, tasks pages etc.
On Fri, Nov 20, 2015 at 10:12:11AM +0100, Ole Streicher wrote:
> 1. Main/landing page
Looks pretty nice - I personally would not use a different location but
would install it right on the Blends page. You usually can not expect
to many responses to discuss about links like this.
> It includes some teasers (after thinking a while about alternatives, I
> guess your [Andreas] solution with just marking them in the task lists
> would be easiest); this would need a "logo" for f.e. astropy.
Getting a logo is a time consuming task - in Debian Med we have not even
an "official" logo. What we currently use is the "best suggestion we
had and somebody has put on the page". By just simply leaving it there
it became somehow official. :-)
> The "More..." link should go to the package description in the package
> list of the blend (taken from Fedoras "labs" page).
You can link to this by just appending the package name as anchor like
> Having four teasers looks optimal for me.
OK, maintaining four paragraphs could probably be done manually.
> An alternative here would be to split into a Landing page and an "About"
> page, as it is done for hamradio:
> However I don't see a need for the split (they duplicate much of the
> content anyway).
Any comment from hamradio (Iain)?
> 2. Tasks list
> This is to be compared with the hamradio tasks list,
> Specifically my table is much simpler: I don't see a need to specify the
> task name *and* the metapackage name; they are quite similar. It there
> it seems unclear what the difference between the "Metapackage" and the
> "Catalogue" links are. I would just move the metapackage name to its
> package list.
> Compared to the original tasks list
> the long descriptions are removed, since they seem to be not needed on
> an overview page, and they often repeat the short descriptions anyway:
> metapackage X in blend Y has short description "X for blend Y" and long
> description "This metapackage install X for blend Y".
I'm fine with this. I think this could be implemented by changing the
> 3. Package list
> That is a rather short example (due to my lazyness), however it should
> work for long lists as well. The original package list to compare is
> I almost squeezed each entry into one line, which gives a nice
> overview. Having only one version number here (the one from the stable
> distribution) is to optimize for the (major?) use case that
> non-developers are visiting us, and they are/should mainly be interested
> in the current stable release.
> For details, one can fold out each entry (shown on the first one,
> eso-midas), and get additional info. I compared to the original, I
> removed some special info (like the supported architectures, and
> versions other the current stable and testing), since they can be found
> in the links.
> Optimally here would be to include more upstream links (from
> d/u/metadata): Bug database, VCS repository, contact) -- are they
> already grabbed?
I admit that would not look as useful for *my* taste. I'm using the
tasks pages for several purposes. I want to see all information without
extra clicks. I do not mind about having an additional shortened look
users might choose at their preference but clicking all the time would
be no option for me.
> What is still completely missing on these mockups:
> * Contact information page, Developer information page
> * An easy navigation menu for the Blend. I am not sure whether the top
> navigation can be used here or whether it should stay as global Debian
I'd be happy about any suggestions here.
> * A debian-astro logo.
I suggest to discuss this on Debian Astro list.
> These mopckup pages are creates with the general Debian CSS, without
> much manual change; so probably some of the "uglyness" is now delegated
> to be solved by the Debian CSS people :-)
I think its a perfectly valid approach to use the general Debian CSS.
> I'd love to get some critics here even before I start to patch around in
> the templates and tasks.py.
Hope these comments are helpful.