Re: Blends pages, tasks pages etc.
Hi Andreas,
Andreas Tille <andreas@an3as.eu> writes:
>> > 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.
Is it that complicated? As far as I can see, this is just one javascript
function: if the URL has a "#all" appended, open all details that were
hidden before. Even for me with limited JS experience this looks quite
simple, or do I miss something important here?
Maybe the reason that the tasks pages were not discussed before is that
it is not clear what they are made for: Are they mainly for our *users*
to help them finding out more for a specific blend, or are they mainly
for us *developers* who want to have a nice overview on different
aspects of our blend?
I tend quite clearly to the first and see them as an advocacy for my
blend -- so that they should be so simple that anyone knowing nothing
about the specifics of Debian can find out what he gets when he installs
"debian-astro". This means to hide everything that is too specific, and
present everything else clearly.
If we *can* manage to put all information that is interesting for
developers on the same page, then it is fine. Otherwise, we can just
create (resp. keep) specific developers taks lists.
>> 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.
It depends IMO where: for developer pages (thermometer etc.), yes
(altough I don't like them personally). However for the task lists, they
seem redundant for me: The page is anyway split by the section, and
each section has a defined color, I don't see a benefit. Especially when
the whole page gets much shorter (because of only one line per package),
the color is not needed to keep the overview.
>> 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.
We could try to implement the pieces that you still miss in my proposal
by keeping the Debian Design there (this is basically an implementation
of the "#all" flag, right?).
Or we could just keep two lists: the current one, for developers, and a
new one for the users. Since I would think that the users page is the
first (and default) to be presented, the existing one would be the
"shadow" one, accessible f.e. from the developers page of the blend.
(We also don't need to have the same solution for all blends).
Best regards
Ole
Reply to: