[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Blends pages, tasks pages etc.

Hi Andreas & all

[about a different presentation for the package lists]:

Andreas Tille wrote:
> Well, I try to make users become "developers" in a sense that they
> provide translations, debtags and so on.  A part of Blends devlopers are
> also users.  So the distinction into two groups users on one side and
> developers on the other side is sometimes hard.

I would in principle see the same -- however, I still hope that there
are considerably more users than developers.

> Moreover I can't see why it should be in the interest of users to
> hide descriptions an screenshots per default.

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 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.

> If you have a long list its good to know where you are.  I agree that
> there is some redundancy.  I think the yellow - green change if "there
> is some work to do" (versions, debtags) should be kept.

I see the lists more for someone who is looking "What can Blend xyz do
for me? Is my favourite program included? What alternatives do I have?";
so for the users. TODO lists have IMO a better place in the QA:


>> 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 repeat: I see no evidence that users are served better with one
> liners.  Please backup your statement by some arguments.

The one-line list give a better overview on the task as a whole. For the
example above, you have all packages on almost one screen page. The old
approach goes over several pages; although it overrides the default
font size to make it smaller.

Finding a specific package (let's say libqfits-dev) takes longer in the
old approach since you have to scroll down and at the same time try to
read the package names (which are also in a small font, and their
columns are mixes with the short description, the home page, the
maintainer, and the long description. At least, they are bold). The
one-line attempt allows to search just with your eyes in a small,
well-structured table (one column just with packages names).

The new approach also allows to read all in one page: just click "show
all details" at the head, and you get the page with all available
details -- similarly to the original page, but like according to the
Debian CSS (so: standard header, standard fonts etc.).

BTW, the hash tags still work:


Best regards


Reply to: