[Bioc-devel] Distinction between release and devel package websites

Hi Andrzej,


On 07/22/2014 10:14 AM, Andrzej Ole? wrote:

Hi all,

I think having links is useful, e.g. for someone who uses BioC release
but wants to install by hand a particular package from the devel
branch.

Distinct colors between release and devel make sense only if one
understands their meaning, which in the end might prove not to be very
useful.

I was thinking of something like this:

  http://www.bioconductor.org/checkResults/3.0/data-experiment-LATEST/

Just a demo. This will be reset to the usual background tomorrow.

Cheers,
H.

I would rather recommend emphasizing the distinction between
release and devel in clear text across the package landing page,
possibly in multiple places, e.g. somewhere close to the actual
package version number; for instance, add the word "devel" after the
version number with a tooltip which will give some explanation/warning
that this is not the stable release version.

The concept of a notification box is far from ideal because it tends
to be annoing to the user and once dismissed 'forever' the user won't
be warned in the future.

I think that the actual problem arises from the fact that the release
landing pages are not clearly prioritized over the devel ones. Maybe
this could be  addressed by preventing the devel pages from being
harvested by google? It could make also sense to emphasize (bold face,
color, ...) the package release landing page on the result list
returned by the search engine on the BioC website. Currently, the
results for release and devel differ only in their relative path,
which can be easily overlooked, and both say "<Package> Home", see
example below:

Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html
           Bioconductor - DESeq2 Home
Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html
           Bioconductor - DESeq2 Home


Cheers,
Andrzej

On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald <jmacdon at 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.gehring at embl.de>
To: "Herv? Pag?s" <hpages at fhcrc.org>, "Michael Lawrence"
<lawrence.michael at gene.com>, "Vincent Carey"
<stvjc at channing.harvard.edu>
Cc: bioc-devel at 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
<stvjc at 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.gehring at 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

           [[alternative HTML version deleted]]

      [[alternative HTML version deleted]]

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

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

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

Hi Andzrej,

thank you, I see your point but I'm afraid I must disagree with you.
I've had this situation numerous times that I have added/fixed
something in the devel branch of a package and had to advice the users
to use this latest version. Needless to say, they were typically using
the release branch, and it was a relatively painless procedure for
them to pick the tarball from the devel landing page and proceed with
manual installation. Of course, this could be also achieved by
installing from the svn, however, this is not very welcome from the
user's perspective.


I'm not sure I understand to need to mix devel and release.  If there is a
bug in the release branch, it should be also patched there.  And if users
need the features of the devel branch, they would have to switch to devel
anyway.


Best
Julian

On Tue, Jul 22, 2014 at 7:10 PM, Andrzej Ole?? <andrzej.oles at gmail.com>
wrote:

Hi Dan, Michael, Julian,

Thank's for keeping the links to the tarballs!

I don't argue that mixing release and devel is a good idea in general.
Rather, that for some users this might be the best compromise between
the following two objectives:
1. a stable working environment
2. the possibility to use or just quickly check a specific new feature
available in the devel version of package X

IMHO this is the road to ruin.

Switching entirely to devel is quite often a no-no for them because of
the unstable nature of the devel branch. And maintaining both release

I personally have never done the homework required to have
both branches on hand with convenient updating.  It is
surely feasible and I would imagine a number of folks reading this have
done it for themselves.  It is probably not trivial to do it portably but a
doc
with suggestions for key platforms would be a nice contribution.  I used
to have Rrel and Rdev scripts that made it work and that is easily worked
out but it is not very elegant and transitioning to new releases of R is
laborious.

and devel only adds to their frustration. As a developer I would like
to have the freedom to advise people on using the latest devel version
of my package regardless of whether they are running release or devel
if I think that this is safe for them, which is typically the case for
many upstream packages without (many) reverse dependencies. I don't
see the point of unnecessary obstructing this approach and I'm not
sure I understand why there is such an outrage about mixing release
and devel. In contrary, quite often this can be much safer than

Depends on your definition of safety.  I think that we have gained much
from the clean separation, in terms of user support effort and freedom to
experiment in devel.  "Experts" can do what they like and deal with the
consequences themselves, but the general approach to the user community
should be principled and it should be: 1) in general, use release branch and
report bugs and see that they are fixed in a timely way; if they are not,
let
the core know -- 2) if you expect help, do all package installations via
biocLite() --
3) we like seeing mileage on the devel branch and encourage its use for
novel features, but it needs to be used with the appropriate version of R
and the
devel package set.

switching between BioC branches. I personally do not want to find
myself in a position when I advice a user to switch to BioC devel
because of some new function from my package he/she would like to give

This is an engineering commitment to a stable release branch.  No new
features,
only bug fixes.  We have benefited from this immensely.

a try only to learn that this broke his/hers scripts (due to the
changes in some other packages).

To sum up, I believe that mixing release and devel might be beneficial
in some specific cases similar to the above described one and it's
important that the infrastructure allows leveraging this approach,
e.g. by providing direct access to devel tarballs.

Cheers,
Andrzej


On Tue, Jul 22, 2014 at 11:12 PM, Julian Gehring <julian.gehring at embl.de>
wrote:

Hi Andzrej,

thank you, I see your point but I'm afraid I must disagree with you.
I've had this situation numerous times that I have added/fixed
something in the devel branch of a package and had to advice the users
to use this latest version. Needless to say, they were typically using
the release branch, and it was a relatively painless procedure for
them to pick the tarball from the devel landing page and proceed with
manual installation. Of course, this could be also achieved by
installing from the svn, however, this is not very welcome from the
user's perspective.


I'm not sure I understand to need to mix devel and release.  If there is

a

bug in the release branch, it should be also patched there.  And if users
need the features of the devel branch, they would have to switch to devel
anyway.


Best
Julian

	[[alternative HTML version deleted]]

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.michael at 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 <mccallm at 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.michael at 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 <jmacdon at 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.gehring at embl.de>
To: "Herv? Pag?s" <hpages at fhcrc.org>, "Michael Lawrence" <
lawrence.michael at gene.com>, "Vincent Carey"
<stvjc at channing.harvard.edu>
Cc: bioc-devel at 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
<stvjc at 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.gehring at 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

           [[alternative HTML version deleted]]

      [[alternative HTML version deleted]]

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

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

Dan has implemented these changes. Go to the Bioconductor home page and in the
search box at the top right enter

   supraHex

(winner of the ISMB 2014 Best Artwork Award! Check out the URL on the package
landing page). You'll see that the first link is to supraHex, and the second to
supraHex (development version).

On the supraHex (development version) page you'll see text indicating that
you're looking at the development version, and for the release you should go
somewhere else.

Further down the installation instructions are now in their own section, adding
a little more emphasis.

The Documentation section includes instructions -- browseVignettes("supraHex")
-- for getting your version of the vignettes.

The 'download' section is now called 'Package Archives'.

The Package Archives section starts with a sentence pointing to Installation
instructions.

Mousing over one of the links pops up a tool tip encouraging you once again to
use biocLite.

Relevant changes also apply to release landing pages.

As Vince mentioned, it is REALLY IMPORTANT that users do not mix release and
devel versions of packages in a single library. Even if it 'works for package
X', this invariably leads to incompatibilities and confusion. For those users
wanting new features, tell them to switch to using the development version,
e.g., as outlined at

   http://bioconductor.org/packages/release/bioc/html/supraHex.html

Thanks for your input,

Martin

On 07/22/2014 12:01 PM, Martin Morgan wrote:

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.michael at 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 <mccallm at 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.michael at 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 <jmacdon at 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.gehring at embl.de>
To: "Herv? Pag?s" <hpages at fhcrc.org>, "Michael Lawrence" <
lawrence.michael at gene.com>, "Vincent Carey"
<stvjc at channing.harvard.edu>
Cc: bioc-devel at 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
<stvjc at 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.gehring at 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

           [[alternative HTML version deleted]]

      [[alternative HTML version deleted]]

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

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

Hi Herv?,

thank you for the demo! Yes, this is definitely much more clear than
just a different color. Maybe we could first implement this idea on
the build/check report websites and see how the uptake will be? I
always keep getting confused by the colors which keep changing with
every release cycle anyway...

Cheers,
Andrzej

On Tue, Jul 22, 2014 at 10:04 PM, Herv? Pag?s <hpages at fhcrc.org> wrote:

Hi Andrzej,


On 07/22/2014 10:14 AM, Andrzej Ole? wrote:

Hi all,

I think having links is useful, e.g. for someone who uses BioC release
but wants to install by hand a particular package from the devel
branch.

Distinct colors between release and devel make sense only if one
understands their meaning, which in the end might prove not to be very
useful.

I was thinking of something like this:

   http://www.bioconductor.org/checkResults/3.0/data-experiment-LATEST/

Just a demo. This will be reset to the usual background tomorrow.

Cheers,
H.

I would rather recommend emphasizing the distinction between
release and devel in clear text across the package landing page,
possibly in multiple places, e.g. somewhere close to the actual
package version number; for instance, add the word "devel" after the
version number with a tooltip which will give some explanation/warning
that this is not the stable release version.

The concept of a notification box is far from ideal because it tends
to be annoing to the user and once dismissed 'forever' the user won't
be warned in the future.

I think that the actual problem arises from the fact that the release
landing pages are not clearly prioritized over the devel ones. Maybe
this could be  addressed by preventing the devel pages from being
harvested by google? It could make also sense to emphasize (bold face,
color, ...) the package release landing page on the result list
returned by the search engine on the BioC website. Currently, the
results for release and devel differ only in their relative path,
which can be easily overlooked, and both say "<Package> Home", see
example below:

Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html
            Bioconductor - DESeq2 Home
Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html
            Bioconductor - DESeq2 Home


Cheers,
Andrzej

On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald <jmacdon at 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.gehring at embl.de>
To: "Herv? Pag?s" <hpages at fhcrc.org>, "Michael Lawrence"
<lawrence.michael at gene.com>, "Vincent Carey"
<stvjc at channing.harvard.edu>
Cc: bioc-devel at 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
<stvjc at 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.gehring at 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

            [[alternative HTML version deleted]]

       [[alternative HTML version deleted]]

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

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

Hi Andrzej,


On 07/22/2014 02:28 PM, Andrzej Ole? wrote:

Hi Herv?,

thank you for the demo! Yes, this is definitely much more clear than
just a different color. Maybe we could first implement this idea on
the build/check report websites and see how the uptake will be? I
always keep getting confused by the colors which keep changing with
every release cycle anyway...

Done:

  http://bioconductor.org/checkResults/3.0/bioc-LATEST/index.html

http://bioconductor.org/checkResults/3.0/data-experiment-LATEST/index.html

Will revert back if there is too much complaining about this...

Cheers,

H.

Cheers,
Andrzej

On Tue, Jul 22, 2014 at 10:04 PM, Herv? Pag?s <hpages at fhcrc.org> wrote:

Hi Andrzej,


On 07/22/2014 10:14 AM, Andrzej Ole? wrote:

Hi all,

I think having links is useful, e.g. for someone who uses BioC release
but wants to install by hand a particular package from the devel
branch.

Distinct colors between release and devel make sense only if one
understands their meaning, which in the end might prove not to be very
useful.

I was thinking of something like this:

   http://www.bioconductor.org/checkResults/3.0/data-experiment-LATEST/

Just a demo. This will be reset to the usual background tomorrow.

Cheers,
H.

I would rather recommend emphasizing the distinction between
release and devel in clear text across the package landing page,
possibly in multiple places, e.g. somewhere close to the actual
package version number; for instance, add the word "devel" after the
version number with a tooltip which will give some explanation/warning
that this is not the stable release version.

The concept of a notification box is far from ideal because it tends
to be annoing to the user and once dismissed 'forever' the user won't
be warned in the future.

I think that the actual problem arises from the fact that the release
landing pages are not clearly prioritized over the devel ones. Maybe
this could be  addressed by preventing the devel pages from being
harvested by google? It could make also sense to emphasize (bold face,
color, ...) the package release landing page on the result list
returned by the search engine on the BioC website. Currently, the
results for release and devel differ only in their relative path,
which can be easily overlooked, and both say "<Package> Home", see
example below:

Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html
            Bioconductor - DESeq2 Home
Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html
            Bioconductor - DESeq2 Home


Cheers,
Andrzej

On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald <jmacdon at 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.gehring at embl.de>
To: "Herv? Pag?s" <hpages at fhcrc.org>, "Michael Lawrence"
<lawrence.michael at gene.com>, "Vincent Carey"
<stvjc at channing.harvard.edu>
Cc: bioc-devel at 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
<stvjc at 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.gehring at 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

            [[alternative HTML version deleted]]

       [[alternative HTML version deleted]]

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

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

On Thu, Jul 24, 2014 at 3:16 AM, Herv? Pag?s <hpages at fhcrc.org> wrote:

Hi Andrzej,


On 07/22/2014 02:28 PM, Andrzej Ole? wrote:

Hi Herv?,

thank you for the demo! Yes, this is definitely much more clear than
just a different color. Maybe we could first implement this idea on
the build/check report websites and see how the uptake will be? I
always keep getting confused by the colors which keep changing with
every release cycle anyway...

Done:

   http://bioconductor.org/checkResults/3.0/bioc-LATEST/index.html

http://bioconductor.org/checkResults/3.0/data-experiment-LATEST/index.html

Will revert back if there is too much complaining about this...

Thanks for all updates. The latter hurts my eyes though -

may I
instead suggest to use a left/right side bar with text "Bioconductor
developer version (3.0)" written sideways.

Alternatively, add
"developer" and "release" tag after each package's version, e.g.
"affycompData 1.2.0 (BioC release 2.14)" and "affycompData 1.3.0 (BioC
developer 3.0)" (possible on a separate line).

BTW, the BioC version is nowhere to be seen on the current check
results pages; it's only from the URL you can infer this.

While at it, it would be great to have links on the check pages that
quickly takes to the corresponding devel/release versions.

 Also, if
one could jump directly to a particular package, that would also be
great, e.g. http://bioconductor.org/checkResults/3.0/data-experiment-LATEST/index.html#gageData

Thxs,

Henrik

Cheers,

H.

Cheers,
Andrzej

On Tue, Jul 22, 2014 at 10:04 PM, Herv? Pag?s <hpages at fhcrc.org> wrote:

Hi Andrzej,


On 07/22/2014 10:14 AM, Andrzej Ole? wrote:

Hi all,

I think having links is useful, e.g. for someone who uses BioC release
but wants to install by hand a particular package from the devel
branch.

Distinct colors between release and devel make sense only if one
understands their meaning, which in the end might prove not to be very
useful.

I was thinking of something like this:

    http://www.bioconductor.org/checkResults/3.0/data-experiment-LATEST/

Just a demo. This will be reset to the usual background tomorrow.

Cheers,
H.

I would rather recommend emphasizing the distinction between
release and devel in clear text across the package landing page,
possibly in multiple places, e.g. somewhere close to the actual
package version number; for instance, add the word "devel" after the
version number with a tooltip which will give some explanation/warning
that this is not the stable release version.

The concept of a notification box is far from ideal because it tends
to be annoing to the user and once dismissed 'forever' the user won't
be warned in the future.

I think that the actual problem arises from the fact that the release
landing pages are not clearly prioritized over the devel ones. Maybe
this could be  addressed by preventing the devel pages from being
harvested by google? It could make also sense to emphasize (bold face,
color, ...) the package release landing page on the result list
returned by the search engine on the BioC website. Currently, the
results for release and devel differ only in their relative path,
which can be easily overlooked, and both say "<Package> Home", see
example below:

Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html
             Bioconductor - DESeq2 Home
Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html
             Bioconductor - DESeq2 Home


Cheers,
Andrzej

On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald <jmacdon at 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.gehring at embl.de>
To: "Herv? Pag?s" <hpages at fhcrc.org>, "Michael Lawrence"
<lawrence.michael at gene.com>, "Vincent Carey"
<stvjc at channing.harvard.edu>
Cc: bioc-devel at 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
<stvjc at 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.gehring at 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

             [[alternative HTML version deleted]]

        [[alternative HTML version deleted]]

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

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

Hi Henrik,


On 07/24/2014 06:03 AM, Henrik Bengtsson wrote:

On Thu, Jul 24, 2014 at 3:16 AM, Herv? Pag?s <hpages at fhcrc.org> wrote:

Hi Andrzej,


On 07/22/2014 02:28 PM, Andrzej Ole? wrote:

Hi Herv?,

thank you for the demo! Yes, this is definitely much more clear than
just a different color. Maybe we could first implement this idea on
the build/check report websites and see how the uptake will be? I
always keep getting confused by the colors which keep changing with
every release cycle anyway...

Done:

   http://bioconductor.org/checkResults/3.0/bioc-LATEST/index.html


http://bioconductor.org/checkResults/3.0/data-experiment-LATEST/index.html

Will revert back if there is too much complaining about this...

Thanks for all updates. The latter hurts my eyes though -

I didn't modify the data experiment report to use a less bright logo
yet. It should auto-update the next time the report is generated though.

may I
instead suggest to use a left/right side bar with text "Bioconductor
developer version (3.0)" written sideways.

We need to deal with a space problem. The report is already too wide.

Alternatively, add
"developer" and "release" tag after each package's version, e.g.
"affycompData 1.2.0 (BioC release 2.14)" and "affycompData 1.3.0 (BioC
developer 3.0)" (possible on a separate line).

Space problem again.

BTW, the BioC version is nowhere to be seen on the current check
results pages; it's only from the URL you can infer this.

It's in the title!

While at it, it would be great to have links on the check pages that
quickly takes to the corresponding devel/release versions.

The check page for devel has links to the devel landing pages and the
check page for release has links to the release release landing pages.
Just click on the name of the package and it will take you to the
corresponding landing page.

 Also, if
one could jump directly to a particular package, that would also be
great, e.g.
http://bioconductor.org/checkResults/3.0/data-experiment-LATEST/index.html#gageData

http://bioconductor.org/checkResults/3.0/bioc-LATEST/aroma.light/

Cheers,
H.

Thxs,

Henrik

Cheers,

H.

Cheers,
Andrzej

On Tue, Jul 22, 2014 at 10:04 PM, Herv? Pag?s <hpages at fhcrc.org> wrote:

Hi Andrzej,


On 07/22/2014 10:14 AM, Andrzej Ole? wrote:

Hi all,

I think having links is useful, e.g. for someone who uses BioC release
but wants to install by hand a particular package from the devel
branch.

Distinct colors between release and devel make sense only if one
understands their meaning, which in the end might prove not to be very
useful.

I was thinking of something like this:


http://www.bioconductor.org/checkResults/3.0/data-experiment-LATEST/

Just a demo. This will be reset to the usual background tomorrow.

Cheers,
H.

I would rather recommend emphasizing the distinction between
release and devel in clear text across the package landing page,
possibly in multiple places, e.g. somewhere close to the actual
package version number; for instance, add the word "devel" after the
version number with a tooltip which will give some explanation/warning
that this is not the stable release version.

The concept of a notification box is far from ideal because it tends
to be annoing to the user and once dismissed 'forever' the user won't
be warned in the future.

I think that the actual problem arises from the fact that the release
landing pages are not clearly prioritized over the devel ones. Maybe
this could be  addressed by preventing the devel pages from being
harvested by google? It could make also sense to emphasize (bold face,
color, ...) the package release landing page on the result list
returned by the search engine on the BioC website. Currently, the
results for release and devel differ only in their relative path,
which can be easily overlooked, and both say "<Package> Home", see
example below:

Bioconductor - DESeq2 - /packages/release/bioc/html/DESeq2.html
             Bioconductor - DESeq2 Home
Bioconductor - DESeq2 - /packages/devel/bioc/html/DESeq2.html
             Bioconductor - DESeq2 Home


Cheers,
Andrzej

On Tue, Jul 22, 2014 at 6:26 PM, James W. MacDonald <jmacdon at 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.gehring at embl.de>
To: "Herv? Pag?s" <hpages at fhcrc.org>, "Michael Lawrence"
<lawrence.michael at gene.com>, "Vincent Carey"
<stvjc at channing.harvard.edu>
Cc: bioc-devel at 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
<stvjc at 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.gehring at 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

             [[alternative HTML version deleted]]

        [[alternative HTML version deleted]]

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

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319

--
Herv? Pag?s

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fhcrc.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319