Thanks everyone for the input.

We'll make some changes (over the next day or so), and then iterate on those as needed. Specifically

1. text after the package title indicating when the user is on the 'developer' page, with link to a 'stable release version'.

2. more prominent Installation header

3. Rename 'Package Downloads' to something less appealing, add text to indicate that the correct way to install a package is to follow Installation instructions, add pop-up interstitial to each of the gz/zip/tgz links to try to further clarify installation.

We might tell google not to index devel packages (but then packages added during a particular release cycle aren't indexed until the next release). We will not change the color of the devel landing page (because color would not have meaning to the uninitiated).

Interesting also that one source of problem is the _vignettes_, not the landing page. Maybe we could add a browseVignettes() code chunk.

Martin

On 07/22/2014 11:10 AM, Matthew McCall wrote:
The current link to the source tarball is called "Package Source" hence the
quotes. Yes, I could check out the package using svn, but when browsing
through a Bioconductor workflow, there are these handy links to the package
pages that let me download and browse the source tarball without having to
type anything. I like the idea of replacing the source tarball link with a
link to the package source in svn.

Best,
Matt




On Tue, Jul 22, 2014 at 1:58 PM, Michael Lawrence <lawrence.mich...@gene.com
wrote:

Just check out from svn to get the source... way easier to keep up to
date, and if you notice an issue, easier to make a patch.




On Tue, Jul 22, 2014 at 10:49 AM, Matthew McCall <mcca...@gmail.com>
wrote:

I hope the "package source" link is not on the proposed list of links to
remove. I often use these links to browse through the source code of
packages to learn from others' work. Also, it seems that making the source
code (even slightly) less accessible would go against the principle of open
source software.

Best,
Matt



On Tue, Jul 22, 2014 at 1:22 PM, Michael Lawrence <
lawrence.mich...@gene.com> wrote:

Agreed. Disabling the links is a good idea. There's really no good reason
for someone to install packages manually. If a user really wants to mix
release/devel, it is still technically possible but this change would
strongly discourage it.

For ensuring the user notices that a page is for the devel version , I'm
still in favor of the simple notification box. Probably without the
option
to hide forever.


On Tue, Jul 22, 2014 at 9:26 AM, James W. MacDonald <jmac...@uw.edu>
wrote:

Given that we have an ongoing problem with people inadvisedly clicking
and
installing things, is there a good rationale for allowing them to do
so?

Perhaps the landing page for each package should be stripped of links
and
replaced with some indication of the availability for each package on
the
various operating systems. There could also be a note indicating that
people can install using biocLite().

Best,

Jim




On 7/22/2014 11:48 AM, Dan Tenenbaum wrote:

Seems like there are two problems, first that the release and devel
pages
look similar, but more importantly that people are downloading and
installing from the package pages when they should be using
biocLite().

I am open to the suggestions for making the release/devel pages look
more
different from each other, but I think something needs to be done
about the
second problem as well. Perhaps a popup that comes up when you click
on a
package tarball saying "The best way to install this is with
biocLite();
are you sure you want to download it?"

Whatever we do probably won't happen until after BioC2014.

Dan


----- Original Message -----

From: "Julian Gehring" <julian.gehr...@embl.de>
To: "Hervé Pagès" <hpa...@fhcrc.org>, "Michael Lawrence" <
lawrence.mich...@gene.com>, "Vincent Carey"
<st...@channing.harvard.edu>
Cc: bioc-devel@r-project.org
Sent: Tuesday, July 22, 2014 8:07:29 AM
Subject: Re: [Bioc-devel] Distinction between release and devel
package
websites

Hi,

Tooltips that appear while hovering over selected links are easy to
miss.  This alone will likely not be clear enough.  We should convey
the
information that the entire website presents a different version of
the
package.

The idea of a notification box that can be made visible by the
individual user seems tempting.  One can combine this with an
optional
cookie, to remember the state between browser sessions.

Changing the layout of the devel page itself will also be helpful to
make the distinction more pronounced.  Hopefully we could approach
this
in a way that maintains the nice design of the bioc website.

Best
Julian


On 21.07.2014 21:50, Hervé Pagès wrote:

Hi,

In addition to these suggestions, how about using a special
background
color for package landing pages in devel?

Cheers,
H.

On 07/21/2014 07:32 PM, Michael Lawrence wrote:

Or an unobtrusive "notification box" that drops down from the top
of the
page, saying something like "this is devel"; there would be a
dismiss
button and a checkbox for whether to show again. The user is free
to
simply
ignore it and proceed as normal.




On Mon, Jul 21, 2014 at 7:10 PM, Vincent Carey
<st...@channing.harvard.edu>
wrote:

  how about a tooltip that reads "installation via biocLite() is
the
recommended approach to Bioconductor software
acquisition, other approaches may lead to inconsistent
package-sets"
that
appears when a reader hovers over a tarball.  i would imagine
that
this is
how the "wrong package" gets installed, by manually using an
inappropriate
tarball.

wrong documentation is not so easy but the doc on the devel
branch might
have a different tooltip cautioning the readers to be sure they
want to
read the doc on the devel version.



On Mon, Jul 21, 2014 at 9:39 PM, Julian Gehring
<julian.gehr...@embl.de>
wrote:

  Hi,

Can we make the package websites for the devel and release
version of a
package more distinguishable?

To elaborate on this: In the past, I have seen several users
having
problems with using bioconductor because they ended up on the
wrong
page
(mostly the devel page when they would have needed the release).
   This
resulted in getting the wrong documentation or installing the
wrong
package.  The pages are well designed, and there is no reason to
change
this.  However, the websites for the devel and release version
of a

package

look almost identical, and that these two get confused seems to
happen to
many users (me included).

If you search for a package within the bioc website, the release
version
always comes first in the search results.  If you are coming
from the
outside (e.g. google), this may not be the case.  In fact,
googling
a few
packages names often returned only the devel page in the top 10
search
results.

What are the feelings regarding this? We could add a header
section on

the

devel page that states that this is an unstable version not
meant to be
used in production settings, and provide a link to the
respective
release
version?

Best wishes
Julian

_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


           [[alternative HTML version deleted]]

_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


      [[alternative HTML version deleted]]

_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
James W. MacDonald, M.S.
Biostatistician
University of Washington
Environmental and Occupational Health Sciences
4225 Roosevelt Way NE, # 100
Seattle WA 98105-6099


         [[alternative HTML version deleted]]


_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




--
Matthew N McCall, PhD
112 Arvine Heights
Rochester, NY 14611
Cell: 202-222-5880







_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109

Location: Arnold Building M1 B861
Phone: (206) 667-2793

_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Reply via email to