Table of Contents | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Logistics
...
- Scott Cantor
- RL "Bob" Morgan
- Philippe ClementBenoit Bailleux
- Paul Trevithick
- Keith Uber
Voting, but not present:
- Axel Nennker
- Keith Uber
Non-voting:
- Benoit BailleuxPhilippe Clement
- Gael Gourmelen
Not present
- Valeska O'Leary
- Gael Gourmelen
- Trent Adams
- Bob Pinhero
Quorate meeting (4 of 5)
2) Minutes
Approved the following minutes (after some minor modifications to section (3) were suggested by Philippe Clement):
...
Scott: I still think we need a "see all" option (as we've stated in our requirements).
Scott: I don't understand what Andrea's alternative to the "icons" are.Scott: I think the 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.
...
- We need to go through the mock-up code
- make sure the components used are compatible with our IPR regime for distribution
- insert into each file (HTML, JS, etc) the applicable copyright notice and reference to the license.
- 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.
...
- 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 detect the header and look a the "capabilities": 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
...
- 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
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