[Go-essp-tech] Transition to CMIP5 production status

Thu Feb 10 07:12:24 MST 2011

Just to raise a couple of points following from what's been said on this thread.  I've made some of these elsewhere so apologies to those who've read them before...

 - An online video tutorial for ESGF would be a great help to explain a technology like OpenID where it requires a shift in thinking to fully understand it and exploit.  At the BADC we've prepared such guides to get people up and running using our various services (http://badc.nerc.ac.uk/help/Webguides_page.html ).  It's saved help desk time.  OpenID is after all something which should be *helping* not hindering users: if fully understood, it's helping the user by removing the need to maintain multiple identities.  It also worth looking at how Yahoo have rolled out OpenID and communicated this to users.  You can now, via OpenID, use Facebook and Google accounts to sign into Yahoo mail and Flickr.  If these are up and running for the general non-technical user across the web surely it can work for the scientific user base for CMIP5.

 - context specific help links in the user interface would help guide users along the steps in any given workflow from search to download of data.

 - The interface for certificate based wget access has only very recently been integrated.  There has not been the same opportunity to test and improve upon as in other pieces in the system.  It's not surprising then that it's not been easy to use.  

Cheers,
Phil

> -----Original Message-----
> From: go-essp-tech-bounces at ucar.edu [mailto:go-essp-tech-
> bounces at ucar.edu] On Behalf Of Estanislao Gonzalez
> Sent: 10 February 2011 08:52
> To: Eric Nienhouse
> Cc: Bell, Gavin M.; Drach, Bob; go-essp-tech at ucar.edu; McCoy, Renata
> Subject: Re: [Go-essp-tech] Transition to CMIP5 production status
> 
> Hi All,
> 
> regarding the usability I think we are falling behind. It's normal to
> have some resistance from new users, as they have to "learn" yet-a-new
> system.
> 
> Still, I'm not 100% sure of all the functionality the Gateway offers,
> nor how to use it. I can only imagine what a new user might feel like.
> I'll give a few examples to be sure I'm not standing on thin air:
> 1) Login: Nobody understands what OpenId is. Most people have already
> an
> OpenId, so they'll try a few and then give up. Some other just try to
> register at every Gateway. Until someone asked me about it, I wasn't
> aware that the questionnaire OpenID doe work wonderfully, as it's part
> of BADCs identity provider.
> 2) Federation-search: Most users might not be aware of the harvesting
> procedure. They'll login at the gateway that "supposedly" contains the
> data, and therefore loggin in to multiple ones (probably until they
> realize everything looks alike...)
> 3) Search: Now I speak for myself. I don't find the search useful at
> all... If I try to find a dataset, I have to make my way through the
> facets. Because putting the dataset name in the search invalidates it
> "Error: Search text contains invalid characters - please use only
> letters and numbers " No dots nor dashes! I can't even search for our
> model....
> 4) Version: the version of the dataset is not easy to see... I think
> that might bring confusion when a new version is published.
> 
> Well, I think we still need to polish a couple of things. Specially
> since there's no help at all.
> 
> And since we are at it. What's with the about page? We, as well as
> BADC,
> have the default one. Where states that the ESG is funded by the DOE
> and
> only a couple of Institutions and Partners are listed... neither MPI,
> DKRZ nor WDCC are mentioned there...
> 
> Just a couple of issues to light the fire.
> 
> Thanks,
> Estani
> 
> Am 09.02.2011 20:23, schrieb Eric Nienhouse:
> > Bryan, All,
> >
> > Agreed on the below.  Deployment and support plan(s) are crucial to
> the
> > initial success of our federated system.
> >
> > I feel we've all spent a lot of good effort on development planning
> and
> > integration system testing in anticipation of the CMIP5 production
> > activity.
> >
> > We need to spend more focused effort on deployment, operations and
> end
> > user support.  Working quickly to get a user support system in place
> is
> > one critical piece IMO.  Bob started a thread on this recently with
> > little feedback.  Let's continue to discuss this and work quickly
> toward
> > an initial proposal.
> >
> > Further, a number of the problems raised involve *usability* of the
> > federated system.  (A sincere thank you to Karl for detailing your
> > recent experiences.)  User experience has highlighted difficulty with
> > Wget using MyProxy certificates, confusion about OpenID and login and
> at
> > least one technical issue related to SSL certificates.  Tiger teams
> are
> > forming to work on these areas.
> >
> > I believe we'll need some true user observation and usability study
> to
> > resolve this well.  In other words, we need to spend more effort on
> the
> > usability of the federated work flows and the system overall.
> >
> > Note that a number of Data Nodes are configured (only) with token
> based
> > file access.  This makes certain Node file access easier for some
> users
> > (IMO), however, we're not achieving the benefit of re-usable Wget
> > scripts in these cases.  Token based access is a possible fall-back
> > option for the near term in my mind.
> >
> > A deployment schedule during this phase will greatly help as there
> may
> > be rapid change in need of end-user evaluation.  In fact, there have
> > already been a number of changes since Karl's work that address some
> of
> > the Wget/MyProxy problems.
> >
> > We need to look carefully at what we as a federation can accomplish
> > given the needs to develop, test, release and deploy multiple
> software
> > components.  Routine upgrades will involve Gateway and Data Node
> > deployments and a coordinated release schedule.  A one week cycle may
> > not be do-able.  However, agreement/commitment to a deployment
> (upgrade)
> > plan is critical.
> >
> > Let's continue to discuss and formalize a near term deployment plan.
> >
> > Apologies for long email - more "thoughts" and "observations" than
> plans
> > - we're meeting to discuss this further at NCAR today.
> >
> > -Eric
> >
> > Bryan Lawrence wrote:
> >> hi Folks
> >>
> >> I think there are two levels of problems being discussed.
> >>
> >> A: We need to "deploy", and have in place a mechanism to "upgrade",
> and
> >>
> >> B: We need "tiger teams" to nail problems.
> >>
> >> A number of instances of B are under way. Good.
> >>
> >> However, I'd like us also to have
> >>
> >> 1) a clear an unabiguous method for "users" to report problems, and
> >> 2) a clear plan for when and how we upgrade during the next few
> weeks.
> >>
> >> I know Stephen has suggested using footprints for 1) (and I'm fine
> with
> >> that, and recommend we do that ... now! ... even if we replace the
> >> system for user support later - which we may need to, since it costs
> >> real money to deploy), and
> >>
> >> We agree something like:  "we will do simultaneous upgrades every
> >> wednesday during the next couple of months (allowing us to agree on
> >> details on a tuesday)."  I don't mind if that's not the plan folks
> agree
> >> on, but I want a plan ...
> >>
> >> All of this is of course independent of  "announcements".
> >>
> >> Bryan
> >>
> >> --
> >> Bryan Lawrence
> >> Director of Environmental Archival and Associated Research
> >> (NCAS/British Atmospheric Data Centre and NCEO/NERC NEODC)
> >> STFC, Rutherford Appleton Laboratory
> >> Phone +44 1235 445012; Fax ... 5848;
> >> Web: home.badc.rl.ac.uk/lawrence
> >>
> > _______________________________________________
> > GO-ESSP-TECH mailing list
> > GO-ESSP-TECH at ucar.edu
> > http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
> 
> 
> --
> Estanislao Gonzalez
> 
> Max-Planck-Institut für Meteorologie (MPI-M)
> Deutsches Klimarechenzentrum (DKRZ) - German Climate Computing Centre
> Room 108 - Bundesstrasse 45a, D-20146 Hamburg, Germany
> 
> Phone:   +49 (40) 46 00 94-126
> E-Mail:  estanislao.gonzalez at zmaw.de
> 
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
-- 
Scanned by iCritical.