Re: Blends pages, tasks pages etc.
Hi Ole,
On Sun, Nov 22, 2015 at 01:50:56PM +0100, Ole Streicher wrote:
> > 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.
I guess if DEP-11 is successful in gathering logos in a defined way
writing an UDD gatherer will be cheap. I've written several gatherers
to get all the information.
> > 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).
I agree that things are not optimal - its just as it is now.
Enhancements for better maintenance are welcome.
> 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
> directly integrated.
For sure I agree in general and it perfectly fits the principle I
followed with the web sentinel to auto generate whatever can be auto
generated. I was just thinking about a temporary solution to have some
design suggestion that could be implemented later with auto generated
data. Its better than having an empty page until the code for the
latter is ready, thought.
> >
> > 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).
OK.
> > 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 :-)
I agree that there is possibly room for enhancement on the tasks pages
but for my taste these suggestions sound a bit complex to me for a
reason that was not brought up before by anybody dealing with the tasks
pages.
> 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.
I agree that adapting to a corporate design could be nice. However, the
colors (green, yellow and red) have some generic meaning and I think
these color scheme needs to be kept.
> Could you think of some compromise here?
Sure.
> Or shall we keep your pages as a shadow structure?
I'm not sure what you mean by this.
> >> 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
> >> menu.
> >
> > 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 :-)
I'm not in conflict with this suggestion. For the moment it was just
way more simple to care only for one domain. You need to know that very
few people work on all this and there are some Blends who not even care
for their simple index pages. Due to my experience it is currently
better to have a general blends.debian.org domain. If you are convinced
that astro.debian.org is helpful for Debian Astro nothing speaks against
such a domain and I guess it will be pretty easy to provide the content
on both sites.
> > 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).
I'm pretty sure that we can find something that is useful for Debian
Astro purpose.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: