ULX Teleconference 2010-11-15

Owned by Former user (Deleted)
Last updated: Nov 22, 2010Version comment
4 min read

Logistics

  • Time: 08:00 PT | 11:00 ET | 16:00 UTC/GMT | 18:00 CEST (Time Chart)
  • Skype: +9900827042954214
  • US Dial-In: +1-201-793-9022
  • Room Code: 295-4214

Agenda

1) Roll Call

Voting:

  1. Scott Cantor
  2. RL "Bob" Morgan
  3. Benoit Bailleux
  4. Paul Trevithick
  5. Keith Uber

Voting, but not present:

  1. Axel Nennker

Non-voting:

  1. Philippe Clement
  2. Gael Gourmelen

Not present

  1. Valeska O'Leary
  2. Trent Adams
  3. Bob Pinhero

Quorate meeting

2) Minutes

Approved the following minutes (after some minor modifications to section (3) were suggested by Philippe Clement):

1) Andreas Solberg's email

http://groups.google.com/group/wg-ulx/browse_frm/thread/71cb40fccefe7079

Scott: I still think we need a "see all" option (as we've stated in our requirements).

Scott: I think Andreas'  "keyword" point is a good one. We need to think of all the kinds of things that the user might want to type on. We don't have a space for that kind of arbitrary information.

Bob: Yes, it seems like this could be a pretty useful open-ended mechanism. ?

Scott: I'm going to mention a Shib call after this. And we'll see if there's interest in having a keyword option. I don't think we should categorize further than just a keyword.

Keith: Aren't categories for higher education useful?

...After some discussion the general consensus was that we should only use keywords and not categories...

Scott: Looks like he has an alternative presentation model. Not sure this is an improvement, but I'll wait to see what others think.

Bob: He showed federation logos if there wasn't a "direct" logo.

Scott: The initial part looks similar. E.g. if you type "ohio" then you just get Ohio State. But if you type "nor" you get a giant list of IdPs. I'm suggesting is that simplicity is better than complexity.

Scott: Shib does not assume that icons will always be available.

Keith: If the top 6 that are there by default and without them then it looks.

Paul: Suggest we change our prototype so that it gracefully degrades if an icon isn't availalble.

...there was general consensus on this...

Scott: I personally would de-emphasize the icons when you start typing.

Keith: If there are small number of entries then showing all of the logos works well. It's natural to select.

Paul: We would have had to come up with a gracefull way to degrade anyway when our mockup becomes dynamic.

2) Trent's email

http://groups.google.com/group/wg-ulx/browse_frm/thread/6dea05e0dcb854c0#

Wherein he suggested:

  1. We need to go through the mock-up code
    1. make sure the components used are compatible with our IPR regime for distribution
    2. insert into each file (HTML, JS, etc) the applicable copyright notice and reference to the license.
  2. Move the mock-up code into a subversion (or similar) repository so we can effectively start tracking version

AI: PAUL: To explore doing the above.

3) Proposed Active Client Selector trigger:
  • ulx://path-to-RP-metadata-JSON-for-HTTP
  • ulxs//path-to-RP-metadata-JSON-for-HTTPS

Paul presented the above and how it is a more universal solution than <object> tags and mime types, etc. Specifically, it works with browsers that don't support some kinds of extensibility (e.g. Mobile Safari, Android/Webkit, etc.)

Scott: I foresee political problems getting agreement on the scheme name (ulx) above.

Paul: To implement the above approach, the RP needs to adapt such that it only shows the above link if there is an active client capability for handling it. This is done by looking the "capabilities" listed in the request header. Actually this brings up another problem: we have no agreement on how to indicate the capabilities of the active client. Hmmm... ULX scope increases yet again.

Scott: This scheme approach is an old trick. But since the W3C is against folks creating new schemes, folks are gun shy about suggesting this. The right way to do this is mime types, but as has been d

4) Finnish selector use case

Keith created the above page.

Paul: If the grouping is optional then the UX if grouping isn't needed would appear as it currently does in our prototype.

Bob: Yes, but is this desirable? Does our notion of universality include this kind of optionality?

Paul: I see what you're saying. You're saying that more optionality be definition leads to increased inconsistency.

Bob: Yes. I'm asking if grouping or non-grouping a legitimate choice.

Scott: there's currently an un-met requirement in the current mockup (i.e. priority IdPs vs. non-priority). So one could capture this notion in something more general that would handle the grouping Keith shows here. The RP could attach its own tags --its own criteria for how the grouping is done.

Keith: What do folks think about priority/ordering?

Scott: I wasn't thinking about using keywords for that. So we don't have a proposal on the table for that. Keywords seems awkward.

Paul: AI: to discuss this with UX person. Is less more. Is this desirable.

Scott: You can't stop people. So the real question is does having some consistency have a benefit vs. a custom UI.

Paul: Keith clearly you believe that having ULX be extended to have support for grouping and priority would be a benefit.

Keith: Yes and these are just two examples of many in Finland.

Paul: I know Scott disagrees, but I like the fact that the username/password there.

Keith: In the second example (example 2) it is a second click away.

Bob: Even though we all agree with approach. 99% of your current users will find this an extra step of course. Just looking around having username/password having to be on a separate page is pretty common.

Adjournment

Next Meeting

  • Time: 08:00 PT | 11:00 ET | 16:00 UTC/GMT (Time Chart)
  • Skype: +9900827042954214
  • US Dial-In: +1-201-793-9022
  • Room Code: 295-4214

We did not discuss the following:

5) Unresolved issues from previous meeting
6) ULX in HTTP request header
  • Proposal: include ISA-related preference info in HTTP request header
  • Info
    • Most important: the user's choice of cloud selector URL
    • Also: a set of user's preferred service providers (e.g. IdPs)
  • How?
    • Long term: Browsers could build this in
    • Short term: a small browser extension could implement
  • Why?
    • Would provide a standard way for the user to exert their preference