[kepler-dev] adding user login interface to Vergil
Laura L. Downey
ldowney at lternet.edu
Tue Sep 13 12:25:39 PDT 2005
That's true Sean -- do you see a browser as analogous to Kepler though? I'm
not quite sure if I do. I'm not sure how our users would see it. If I
think about the feedback so far from the couple of workshops that have been
done, the scientists are looking at Kepler as this "all-in-one" application
on their desktop, as a one point of entry for them to do workflow design and
analysis and for the system to basically manage all the behind the scenes
stuff and to hide it from them. Logging in once at the beginning
accomplishes that objective. Once they have logged in they have access to
whatever they have been granted permission to have access to and they don't
have to think about that any longer during their session. Whatever searches
they do, whatever resources they access, whatever workflows they run etc
will all run seamlessly because they have logged in.
And I can tell you from running usability tests on the web that there are
still plenty of users out there wondering why they have to sign in at so
many places to get to things. They think of the internet as this one big
thing -- in fact I think there is even a website that is trying to sell
itself as a single sign on solution where if you use the same id and
password on several sites you can have this one site save it for you, then
automatically log you in whenever you go to a website that requires a log
in. Of course there are all kinds of problems with this and it doesn't work
everywhere because different sites have different requirements for usernames
and passwords etc. But it is interesting that someone is trying to solve
this issue for users that don't want to have to log into multiple sites on
the web.
And now that I've just said that I could make the analogy that websites that
require log ins are like applications that require log ins at the start up.
;-)
Laura L. Downey
Senior Usability Engineer
LTER Network Office
Department of Biology, MSC03 2020
1 University of New Mexico
Albuquerque, NM 87131-0001
505.277.3157 phone
505.277-2541 fax
ldowney at lternet.edu
-----Original Message-----
From: Shawn Bowers [mailto:sbowers at ucdavis.edu]
Sent: Tuesday, September 13, 2005 1:09 PM
To: Laura L. Downey
Cc: guan at sdsc.edu; 'Jing Tao'; kepler-dev at ecoinformatics.org
Subject: Re: [kepler-dev] adding user login interface to Vergil
Just as a quick note, a Web browser is one example of a system in which
you don't log in at startup, but instead login occurs "at the source of
contact," i.e., when a particular application/web page is started. Note
also that there is some notion of multiple login accounts (stored
locally), certificate management, etc.
A similar "modality" could also be employed in Kepler (although I'm not
advocating either approach, just throwing it out there).
-shawn
Laura L. Downey wrote:
> 1. Am I understanding you correctly that you are suggesting that as each
> workflow is run, if it uses a grid resource, that is when the kepler
system
> would prompt a user to log in? I assume a user would remain logged in
until
> they specifically logged out.
>
> The advantages to having a user log in upon start of the application are
1)
> it is fairly standard way of interaction in a network application 2) that
> he/she knows immediately what they have access to and 3) that they are
> logged in and won't have to interrupt their design and execution process
> later to log in. 4) Additionally, they will also figure out real quick if
> they need to apply for an account on a domain so they have access to
desired
> resources etc.
>
> Is there something I'm missing here? Is there some advantage to not being
> "logged in" in terms of performance or something? You seem to be placing
a
> significant emphasis on people not having to log in or them working a lot
of
> the time locally so it being some bother to the user to log in etc. Do we
> anticipate that users will want to do lots of stuff locally? I had
assumed
> just the opposite that the most likely scenario is that users will want
> access to whatever they have permission for in order to fully exploit
> resources.
>
> 2 & 3. Without addressing some of the underlying technical issues since
my
> focus is the user ;-) .... from a user perspective I think it will be
> important that users know/understand what they have access to, what they
are
> allowed to do and run etc.
>
> Laura L. Downey
> Senior Usability Engineer
> LTER Network Office
> Department of Biology, MSC03 2020
> 1 University of New Mexico
> Albuquerque, NM 87131-0001
> 505.277.3157 phone
> 505.277-2541 fax
> ldowney at lternet.edu
>
>
> -----Original Message-----
> From: Zhijie Guan [mailto:guan at sdsc.edu]
> Sent: Tuesday, September 13, 2005 11:40 AM
> To: 'Laura L. Downey'; 'Jing Tao'
> Cc: kepler-dev at ecoinformatics.org
> Subject: RE: [kepler-dev] adding user login interface to Vergil
>
> Here are my concerns about user login and resources.
>
> 1. I prefer Kepler system pops up a window for user login at the execution
> time. During design period, users don't need to input username/password
once
> they add a Grid actor into the workflow. So I guess the director in each
> workflow should somehow check all the actors before initializing the
> execution, and then prompt for username/password/domain if any Grid actors
> are used. The director should also store the proxy created by GAMA server
> and finally destroy it when the workflow is finished/ceased. Thus, users
who
> don't use Grid actors won't be bothered to log in. Yes. I agree a menu
entry
> of user login now seems confusing. Kepler system should handle the whole
> issue instead of depend on users self consciousness.
>
> 2. Resources, as well as access, need more discussion and specification.
> Resources could be data, programs (tools), a physical machine, a cluster,
> conceptual computing power, or even human interaction (like checking the
> result with EXPERIENCED EYES). Access could be retrieving the data,
> executing a program, consuming a web/grid service, or any combination of
> them. Note some resources only support one kind of access, like a FTP
server
> only provides data access, users cannot run any program on it. If the
> "resources" means the "domains", we still need to know a user having
access
> to a domain does not mean (s)he can run any kind of programs on any
> computers in that domain. I don't think I have a clear mind on this
resource
> accessibility issue. I still need users (GEON/SEEK groups?) give me more
> feedback.
>
> 3. The access permission is another issue related to resources and access.
> We have access to a resource does not mean we can fully control the
> resource, just like access to a directory in Unix does not mean the whole
> "rwx" permission. In a Grid environment, it may get to be more complicated
> with the Grid user account. A GIS+GSI architecture may satisfy our needs
if
> we really want to build up a complete list for access permission of each
> access to each resource. But in that case, a Grid job scheduler should
> handle all the resource access control and job dispatch, as well as cover
> the details to the end user. To my understanding, the ultimate goal of
> workflow platform includes choosing the resources for the users, instead
of
> letting users make the decision. I believe there is still a lot of
> research/development to do in this way. I would like to start our Kepler
> authentication framework with an easy, contact functional component while
> keeping all of those considerations in mind.
>
>
> Zhijie
>
>
>
> -----Original Message-----
> From: Laura L. Downey [mailto:ldowney at lternet.edu]
> Sent: Tuesday, September 13, 2005 8:19 AM
> To: 'Jing Tao'; 'Zhijie Guan'
> Cc: kepler-dev at ecoinformatics.org
> Subject: RE: [kepler-dev] adding user login interface to Vergil
>
> A few additional comments....
>
> No worries Matt on not commenting on the log in and authentication
screens.
> I put them together quickly. The mockups were to give the general design
> idea that goes along with the proposed overall re-design.
>
> The reason I suggested to Zhije to have a look was not to imply that it
was
> a final design but just to give an idea of the overall design so that he
> didn't mock something up that didn't fit. Just trying to get us moving in
> the general direction of the proposed re-design as we make changes so we
> have less to change later on when we get the full re-design implemented.
>
> The wording on the dialogs can easily be changed and I even made reference
> to that. Deana made the same comment about the word "demo" being used and
I
> only used it because it is used in the problem description on the wiki
page
> (demo account). No problem with choosing something different. Same goes
> for the placeholder "email XXX for an account." I didn't have anything
> specific so just stuck that in there.
>
> As to the user being prompted to log in, Ilkay and I discussed that and it
> was my understanding that was the way things were to be designed so I went
> with that. I don't think users would be confused at having to log in to
the
> application at the beginning, I believe that is fairly standard on
> networking applications that use distributed resources. And people using
> the local resources versus grid resources is analogous to working offline
> and online which is also somewhat standard in networked applications.
>
> I think it would be more confusing for the user not to be prompted to log
in
> and think they have access, only to realize later they don't and have to
go
> looking for a place to "log-in" to get access to other resources. Logging
> in at the beginning of a session or use of an application seems the most
> logical and standard approach to me. And if users consciously log out,
then
> want to log back in, they are aware because they made the choice. But to
> just open the app and expect them to know they are not logged in doesn't
> seem the best design in my experience.
>
> In terms of the issue of resources, that is a general term and could mean
> "domain" if we need it to. Perhaps I have misunderstood the requirements
> here but I thought it was necessary that users know what they have access
to
> and what they don't. I know if I was a user this information would be
> important. Especially if they are doing searching and see a resource
> returned but can't get it because they don't have permission etc. Or if
> they want to run a workflow remotely but don't have access to the domain
or
> resource that workflow is on.
>
> Again, the mockups were designed as an interim solution until we get a
more
> sophisticated role-based access model working which may make the problem
of
> knowing which resources a user has access too a moot point.
>
> Laura L. Downey
> Senior Usability Engineer
> LTER Network Office
> Department of Biology, MSC03 2020
> 1 University of New Mexico
> Albuquerque, NM 87131-0001
> 505.277.3157 phone
> 505.277-2541 fax
> ldowney at lternet.edu
>
> -----Original Message-----
> From: Jing Tao [mailto:tao at nceas.ucsb.edu]
> Sent: Monday, September 12, 2005 4:55 PM
> To: Zhijie Guan
> Cc: Laura L. Downey; kepler-dev at ecoinformatics.org
> Subject: Re: [kepler-dev] adding user login interface to Vergil
>
> Hi, Zhijie:
>
> See my comment below the text.
>
> Jing Tao
> National Center for Ecological
> Analysis and Synthesis (NCEAS)
> 735 State St. Suite 204
> Santa Barbara, CA 93101
>
> On Mon, 12 Sep 2005, Zhijie Guan wrote:
>
>
>>Date: Mon, 12 Sep 2005 13:32:34 -0700 (PDT)
>>From: Zhijie Guan <guan at sdsc.edu>
>>To: Laura L. Downey <ldowney at lternet.edu>
>>Cc: kepler-dev at ecoinformatics.org
>>Subject: Re: [kepler-dev] adding user login interface to Vergil
>>
>>
>>That post is realy great. Sorry I forgot to get track on this. I did
>>check the prototypes when you posted, and thought they were just a general
>>idea instead of real implementation. It's my fault.
>>
>>Just a few comments. I cannot post it on wiki pages since I do not have an
>>account yet.
>>
>>1. The Kepler user may not "have to" log in before using Kepler. Though
>>most of our users will be registered with the GAMA server, we still have
>>some users who do not belong to any current-known group. An anonymous user
>>account may be the alternative solution. But I doubt the users would like
>>to log in when they just want to use their local resources. That's why I
>>suggest the authentication dialog is integrated as a menu entry. So users
>>can log in when necessary.
>>
>
>
> I agree with you. If user didn't log in, it runs kepler as public and
> he/she has a limit to access some resources.
>
>
>
>>2. For the "domain" part, I am not sure if we still need to know the
>>user's domain(s). I remember Jing said the GAMA server (actually the
>>MyProxy) could contact various LDAP servers to get the user
>>authentication. In that case, no domain info is needed. We can either use
>>the user-inputed domain info to locate the LDAP server, or let the GAMA
>>server do the flooding search.
>>
>
>
> Does the domain mean Organization? If it does, I think we need the domain
> part, otherwise user should input the string looks like
> "uid=john,o=NCEAS...". It is pain for user.
>
> MyPoxy can contact to one main LDAP server, and main LDAP may referral to
> another LDAP server according to organization info for the user. So our
> system need domain info and it is convenient for user just select an
> domain for option list.
>
>
>
>>Jing: Since we have the user interface already, should we start the design
>>of the AuthenticationManager as you mentioned?
>>
>
> Yep, we can start it now. We can discuss it with matt, lkay and efrat.
>
>
>
>>Thanks!
>>
>>Zhijie
>>
>>
>>On Mon, 12 Sep 2005, Laura L. Downey wrote:
>>
>>
>>>I'm confused. I made a post to seek-dev about the log-in screen and
>
> pointed
>
>>>people to the wiki some time ago. Here's the url to the log-in and
>>>authentication mockups:
>>>
>>>http://kepler-project.org/Wiki.jsp?page=KeplerAuthenticationFramework
>>>
>>>I asked for feedback and got a few minor comments.
>>>
>>>The proposal was for the user to have to log in before getting to the
>
> other
>
>>>Kepler screens so not really a need for a log-in menu item -- this was a
>>>first cut solution until we add in more sophisticated role based access
>
> etc.
>
>>>Laura L. Downey
>>>Senior Usability Engineer
>>>LTER Network Office
>>>Department of Biology, MSC03 2020
>>>1 University of New Mexico
>>>Albuquerque, NM 87131-0001
>>>505.277.3157 phone
>>>505.277-2541 fax
>>>ldowney at lternet.edu
>>>
>>>
>>>-----Original Message-----
>>>From: Matt Jones [mailto:jones at nceas.ucsb.edu]
>>>Sent: Monday, September 12, 2005 1:00 PM
>>>To: Zhijie Guan
>>>Cc: Laura L. Downey; kepler-dev at ecoinformatics.org
>>>Subject: Re: [kepler-dev] adding user login interface to Vergil
>>>
>>>Zhijie,
>>>
>>>Those dialogs ahve already been prototyped but not fully reviewed before
>>>implementaiton starts. Maybe Laura could post them on the usability
>>>page or somewhere else on the wiki so that we can all comment before you
>>>start implementing? Thanks,
>>>
>>>Matt
>>>
>>>Zhijie Guan wrote:
>>>
>>>>Thanks for pointing me to the right issue. I've read the wiki webpage on
>>>>http://kepler-project.org/Wiki.jsp?page=KeplerUsability, which includes
>>>>the proposal of Kepler redesign and Kepler Symbology. It is quite
>>>>interesting to see a new look of Kepler.
>>>>
>>>>For the changes I would make, they are only a menu entry and a user
>
> login
>
>>>>dialog. They should be easily adapted to any schema/rationale with minor
>>>>changes on the source code. And finally I will submit my changes to
>
> Ilkay
>
>>>>for CVS check in.
>>>>
>>>>Thanks!
>>>>
>>>>Zhijie
>>>>
>>>>On Mon, 12 Sep 2005, Laura L. Downey wrote:
>>>>
>>>>
>>>>
>>>>>Before making lots of changes, I would suggest that you look at the
>>>
>>>proposed
>>>
>>>>>re-design for the user interface. Also, I've already designed the user
>>>
>>>log
>>>
>>>>>in screens and generally how they will be integrated into that design.
>>>>>
>>>>>I'd post the pointer to the wiki page but I can't seem to get the
>
> Kepler
>
>>>>>project pages to display at the moment.
>>>>>
>>>>>Laura L. Downey
>>>>>Senior Usability Engineer
>>>>>LTER Network Office
>>>>>Department of Biology, MSC03 2020
>>>>>1 University of New Mexico
>>>>>Albuquerque, NM 87131-0001
>>>>>505.277.3157 phone
>>>>>505.277-2541 fax
>>>>>ldowney at lternet.edu
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: kepler-dev-bounces at ecoinformatics.org
>>>>>[mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Zhijie Guan
>>>>>Sent: Wednesday, September 07, 2005 4:49 PM
>>>>>To: kepler-dev at ecoinformatics.org
>>>>>Subject: [kepler-dev] adding user login interface to Vergil
>>>>>
>>>>>Dear All,
>>>>>
>>>>>I get a question for editing the "graph editor" user interface. I am
>
> going
>
>>>>>to implement the single login user interface for Kepler authentication
>>>>>framework. Thus, I need to add a menu entry into the "Graph Editor"
>
> user
>
>>>>>interface. When user click this menu entry, the system should pop up a
>>>>>dialog to let user input username and password. But I don't know where
>
> I
>
>>>>>should start in order to edit the user interface (Vergil?). I am pretty
>>>>>new to the Kepler code jungle. Could anyone point me any source
>>>>>code/development documents that I should read?
>>>>>
>>>>>Thank you!
>>>>>
>>>>>Regards,
>>>>>
>>>>>Zhijie Guan
>>>>>
>>>>>_______________________________________________
>>>>>Kepler-dev mailing list
>>>>>Kepler-dev at ecoinformatics.org
>>>>>
>
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>>>>
>>>>_______________________________________________
>>>>Kepler-dev mailing list
>>>>Kepler-dev at ecoinformatics.org
>>>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>
>>>
>>
>>
>>
>>
>>_______________________________________________
>>Kepler-dev mailing list
>>Kepler-dev at ecoinformatics.org
>>http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>
>
>
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
More information about the Kepler-dev
mailing list