Re: Blends pages, tasks pages etc.
Andreas Tille <email@example.com> writes:
> On Sat, Dec 05, 2015 at 02:45:43PM +0100, Ole Streicher wrote:
>> It is just the long description that is hidden -- the short one is
>> visible and gives a good hint of what the program does. This is what I
>> would expect a user to look for if he browses a lengthy list. If he is
>> interested, the longer description is just one click away.
> I keep on failing how you draw the conclusion what users are
OK, so could you describe what the expections of the users here are?
>> > I asked *several* users and they like the pages as they are. I have
>> > no idea about astronomy users.
>> I would guess this is not so much about the field of interest but
>> whether you ask new users or older ones. This is basically the same as a
>> layout change of a newspaper -- regular users tend to want the old
>> version kept.
> Sorry, you are wrong here: I asked always *new* users (after talks
> presenting it or asking new colleagues).
I misunderstood you here, sorry. I thought that you had asked people to
compare the current approach with the alternative one.
> Users are also very keen on seeing relevant publications.
What dou you mean here? Publications are included in my design. See
as an example.
>> >> 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?).
>> > I'd be interested in seeing this to enable evaluation and hearing opinions.
>> I now uploaded a working version for the Debian Astro Blend. As a typical
>> example , you could take the "Development" list
>> and compare it with f.e. the old (similar) science/astronomy-dev task list:
> I admit I do absolutely not like the shortened list since it is
> something totally different than it was intended.
Is not shortened at all. It contains almost everything what is in the
current approach. So, it has *additionally* to what you intended (please
write a few words about this) the advantage that one can have a better
overview if one likes.
What exactly are you missing there?
> I do not care for the size but the fact that we have the entire
> information about the packages.
This is there in my approach as well. You can have it selectively per
package (what I would prefer), or in one big piece (with the "#all"
hash). Switching between them is just one click.
But, page length finally *does* matter. Nobody wants to go though a
> You simply want something else which is fine but please do not
> describe it as replacement for the existing tasks pages.
It can IMO replace it since it has the original content (minus the parts
that I still didn't implement yet).