Re: Publication information for tasks pages
[Christoph, please read the marked **** paragraph about screenshots and
perhaps comment on this in a CC to the list. Thanks.]
On Wed, Sep 02, 2009 at 05:11:58PM +0200, Michael Banck wrote:
> However, at a quick glance, I only see "Please cite: " entries in the
> task overview page, no further references, did I overlook something?
No, you did not. Adding "Publication-*" fields to a dependency will
result in a "Please cite" paragraph in the end of the section for this
package on the tasks pages. What did you expected?
> By the way, maybe it would be better and clearer to have that as "Cite
> as: " rather, to send a bit stronger message that citing might not be
> voluntary if you publish something (and might pre-empt complaints from
> upstreams, dunno).
Fine for me. I asked for remarks about wording and layout so your
comment is welcome. Anybody else for replacing the "friendly" version
by the stronger one?
**** screenshots.debian.net ****
> 1. The screenshot thumbnails are unnecessarily small and the box they
> are in has a big margin (at least on my 1024x768 gecko browser); I guess
> that is a problem with screenshots.debian.net, but really - the
> thumbnails are useless. If they were twice as big, they would probably
> still fit into the free space and be useful.
I agree that in the current form it is rather a binary information:
There is a screenshot or there is none. While I think this is a helpful
piece of information I agree that double sized icons would look better.
For the problem of enlarging the screenshot if you are moving the mouse
on it: EVERYBODY IS VERY WELCOME TO PROVIDE BETTER CODE TO ENHANCE THE
DISPLAY! Sorry for shouting. ;-) But I for myself see *my* part of
the Blends work in gathering structural information. If anybody wants
to add more sugar on the pages I'd be *really* happy.
> 2. I know it's difficult, but I think it would be worthwhile to simpify
> the version/arch table. E.g. I am not sure arch information is needed
> for all arches - maybe just scientifically interesting ones (i.e. mostly
> i386, powerpc, amd64, ia64) or for a number of specifically tagged
> packages where we think architecture information is actually important
> (e.g. openmpi/other mpi implementation etc.). In any case, I suggest to
> use aliases for the architectures, like "Intel/AMD 32bit", "Intel/AMD
> 64bit" and "Intel Itanium" or so.
>
> 3. Same goes for versions - maybe if the same version is available in
> stable and testing (or unstable), only mention stable; maybe use
> stable/testing/unstable (or even "Debian 4.0 (etch)", "Debian 5.0
> (lenny)") instead of codenames (also note that codenames are sorted
> alphabetically right now - sid is before squeeze). Also, binNMUS are
> displayed seperately - maybe it makes even sense to just show the
> upstream version?
Nice to see that others have the same problem with this as I myself.
I'm always constantly thinking about how to enhance this table when it
comes to really long tables. I ended up with similar considerations as
you - I hope to come up with some more reasonable in the future. (As
always: Patches are welcome.)
> 4. the java-script(?) pop-ups for tags and especially versions/arches
> are a bit in your face. I think having some extender-like facility
> which dynamically extends the package's entry and displays the
> information.
Anybody experienced in web design might like to have a look at
svn://svn.debian.org/blends/blends/trunk/webtools/templates/tasks.xhtml
any suggestion for enhancement is welcome. I decided for the buttons
because my logic was "Yellow button means work to do, green button means
that things seem to be fine." I don't know how to apply this logic into
hidden extenders - but that's probably my small experience in web
design.
> Following-up on the last though on 3. - did you consider having a
> user-view and seperate developer-view? The former could be simpler and
> only show information a user might want (mainstream architectures,
> upstream versions, etc.); whereas the developer view would show detailed
> version information to diagnose e.g. missing or failed builds.
I would consider the use of this feature very low compared to other
things on my agenda - so no, I did not considered this and see no strong
reason to put this on my todo list (in contrast to the other very
interesting suggestions above).
> Sorry for this rather uncoherent brain dump...
No need to sorry. It's perfectly OK and with exception of item 5.
I completely agree that there is room for enhancements. For some of
them I see chances to work on myself for the others I'm hoping for
any takers.
Kind regards and thanks for your thoughts
Andreas.
--
http://fam-tille.de
Klarmachen zum Ändern!
Reply to: