Re: Blends pages, tasks pages etc.
Andreas Tille <email@example.com> writes:
> On Fri, Nov 20, 2015 at 10:12:11AM +0100, Ole Streicher wrote:
> 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.
Since it was/is just an (incomplete) mockup, I was worrying a bit about
to destroy something. Also I have a small technical problem (I use
testing everywhere, and jekyll isn't installable in the moment).
>> 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.
I didn't mean the Debian-Astro Logo, but Logos for individual
packages. They are still not in Debian yet, and even if they were
(DEP-11), they also would need to be accessible via UDD or so.
>> 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
Thanks, I'll do that.
>> Having four teasers looks optimal for me.
> OK, maintaining four paragraphs could probably be done manually.
I would in any case take the content (short description, home page, link
to package description) from the UDD.
What is not ideal then is that the teasers (which are likely to be
changed from time to time) are hidden deep in the web page
(directory webtools/templates/ or so, and in a quite complex file).
Maybe having your idea of a flag in the lists is better? At least, after
creating the mockup I like your idea more than having the teasers
>> 2. Tasks list
> I'm fine with this. I think this could be implemented by changing the
> tasks_idx.xhtml template.
I have it ready, but need to checkin it (doing so on Monday).
>> 3. Package list
> 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.
I was a bit afraid of that. However: In my opinion the major use for
these pages is to attract new users, and they will probably first have
an overview of what is there, with the possibility of a deeper look.
An option could be to have a link on top of the page that opens the
details of *all* packages. That would be one click instead of many --
or if the web page is called weit a specific anchor (like
"education/astro.html#all") one could also get the page with all
details. This could even go into a cookie, if someone has the skills to
implement it :-)
It would be however not so colorful as you design, but I am afraid that
these colors don't fit into Debian's corporate design.
Could you think of some compromise here? Or shall we keep your pages as
a shadow structure?
>> What is still completely missing on these mockups:
>> * Contact information page, Developer information page
I now created a contact page (taken from hamradio) and a developer
page. The last is probably really blend specific (ours f.e. has a
section about the sprint).
>> * 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.
The Debian web design page says that the global menu can be subdomain
specific. I don't think that we need a global "blends" subdomain
specific menu, so we could "abuse" it for us -- see the current mockup
version: it has as global menu "Debian Astro - Metapackages - Contact -
Contribute". The link back to the "blends" home page is the first
breadcrumb, so we don't need it elsewhere.
Probably people find to one of the Blends since they are interested in a
specific topic -- from our point of view all Blends are similar, but
a user will probably rarely use more than one Blend. The inner structure
of a blend is much more important then links between Blends. Therefore,
it may be even useful to reserve subdomains for them: for me
"astro.debian.org" and "astronomy.debian.org" which should point to the
according Blends homepage. And then we also had a good excuse to use the
global menu :-)
>> * A debian-astro logo.
> I suggest to discuss this on Debian Astro list.
Sure. I'll du that.
> Hope these comments are helpful.
I am going to implement the pages -- however we should get some
agreement on the individual tasks pages (either to have a compromise or
to distribute both).