See also: IRC log
<Ian> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html
<Ian> [IJ notes for the call: DSR items, privacy considerations, exception considerations]
Manu: Any changes to agenda today?
<Ian> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html
Ian: I'm most interested in the structure - have some structural points / questions.
<scribe> scribe: manu
<Ian> +1 to short labels for (micro) use cases
Ian: There are a couple of things that are good... +1 to short labels for micro use cases
ian: Industry folks tend to throw
around short labels quite a bit - especially in these cases,
slightly higher level - short phrase that speaks to industry
doesn't get in way of easy understanding.
... I like that.
... I think the green and the red is distracting.
... Minor comment, but maybe we can find some other way to
format some metadata.
... There were times when Dave mentioned exception situations -
when a payment fails and coupon needs to be re-instated.
Thinking about those and putting them in use cases at that high
level seems like an annotation about an exception
situation.
... Other topic that's come up has been privacy considerations
- remember that you don't want to send your Social Security
Number over to a merchant, for example.
... Not sure what "Justification" is yet?
<Ian> Manu: Agree green/red is distracting. Red is editorial (to be stripped out).
<Ian> ...the Justification bit is to explain why it's different than another use cases
https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#discovery-of-offer
<Ian> IJ: Justification is why we have the use case at all
<Ian> ...but it's there for the editors.
Ian: Ok, we may want arbitrary
notes - why this is important... which is slightly different
than editorial notes.
... If a lot of them have the same justification, we could have
a section that's assumptions - why did we include these use
cases overall?
... For example, help ensure ubiquity, etc.
<Ian> IJ: Maybe they don't have common justifications (so does not make sense to factor out)
Ian: Let's read through a few of
them... (reads through Website-based offer)
... Themes - automation is important - need unifying
architecture given diversity of devices, applies to automotive,
point of sale, etc.
... So, there might be able to pull out the justifications - we
might be able to figure out if it contributes anything to
certain topics.
... Automation, legal obligations, security, etc. These are
clearly perceived needs...
<Ian> Manu: What you did in your doc....
manu: here - http://www.w3.org/2015/03/wpay-usecases.html
<Ian> ...you did break it into categories
Ian: The justification you have, I like the idea that we say 'how did any use case get into this document to begin with?'?
<Ian> https://www.w3.org/Payments/IG/wiki/ExecSummary#Goals
<Ian> do they improve usability?
<Ian> security?
Ian: If the group could see the broad things we wanted to address - tying them into the goals - do they improve usability?
<Ian> porttability?
Ian: We believe these are "in
pursuit of these goals"... here's the goal it helps us
pursue.
... So now everyone in the group knows why it made it in here -
it's in pursuit of some goal, otherwise it shouldn't be in
here.
... We should attempt to do that - that would simplify the
document by making it short labels... that's different from
editorial notes, like "is this a duplicate?"
... Categories that I had in my document were intended to group
things slightly differently - avoid duplication of use cases -
putting them next to each other, when they differ by a tiny
amount, I had a common label for them.
<Ian> Manu: One thing I found moving them into the use cases, I could find a slightly different justification for each use case
<Ian> ...there was a use case where hold/pre-auth was so close that I think we can put them into one use case
Ian: You have a number of things under "Discovery of Offer" - if we say what goal it helps us pursue - that might be useful... having everything flow from a small number of goals would be nice... so having an annotation wrt. about what the group likes about this model. For example, the purchase price of the train in the first example of $15 might be important because the price.
<Ian> TEMPLATE
<Ian> - short label
<Ian> - the short story
<Ian> - annotations:
<Ian> - priority
<Ian> - motivation
<Ian> - security / privacy considerations
<Ian> - exceptions
Manu: So, if we add each one of those subtopics for each micro use case - we don't have micro-use cases anymore.
<Ian> - which goals do they help use pursue
Ian: Without trying to be fancy - possible to have one view that's just the simple statements w/o anything else - another one that's the fully annotated one - push the button to do the annotation.
<ShaneM> sorry my mute button stopped working!
<Ian> IJ: Can we expand good bits?
<Ian> Manu: We can built that but we don't get it for free
Ian: I have the feeling that a
designer could make this still readable...
... The sentence could be big - if it was airy to read - might
not be too painful.
<Zakim> manu, you wanted to mention Motivations.
<Ian> Manu: We could put security/privacy, and exceptions in their own sections
Ian: Yes and no - Dave's comment
was - I want to pay with a voucher - please note that if a
payment fails, I get my voucher back.
... On another hand, there are probably general statements that
can be made. For example - transactions can stop at any time,
so in those cases, what do we need to keep in mind when that
happens?
... It could be that exceptions merit it's own document
section.
... For security/privacy - it's sort of the same - we want to
make sure that when we get to the architecture that we're able
to send data to only the parties that need it.
... For example, data sent to merchant is only to be shared w/
the merchant - that seems like a useful/general statement.
However, there could be, in a specific use case, it could be
that we want to call out something.
Manu: I'll try a few things and you can try a few things - maybe we can come up with a workable template.
<Ian> PROPOSED:
<Ian> * REQUIRED:
<Ian> - short label
<Ian> - micro statement
<Ian> - goals
<Ian> * OPTIONAL
<Ian> - motivation
<Ian> Manu: Let's make motivation mandatory.
<Ian> IJ: Ok
<Ian> * OPTIONAL
<Ian> - security/privacy considerations
<Ian> - exception considerations
Ian: Does this flow make sense to you?
Kepeng_Alibaba: Yes.
<Ian> http://www.w3.org/2015/03/wpay-usecases.html
Ian: I put in a bunch of use
cases in this document if I could make them fit - tried to draw
on slide decks, use cases, dave's comments.
... On the one hand I don't feel strongly about which ones make
it in - curious about yoru plan to bring them in.
Kepeng_Alibaba: One question - as part of the payment method - because we have Alipay, largest payment method in China, but it's not mentioned in use cases document.
<Ian> Manu: Yes, we should mention it somewhere.
<Ian> Manu: We need to understand the Alipay flow to figure out how to include it.
<Ian> Initiation of Processing. Depending on the payment instrument, the payer (e.g., when using PayPal), the payee (e.g., when using a credit card), or other party (e.g., bank) initiates processing.
Ian: Where we mention PayPal or Google Wallet - we could also mention Alipay.
<Ian> Ian: Let's put PayPal, Google Wallet, Alipay, Apple Pay
<Ian> IJ: We should also list Ripple or other cryptocurrencies where we mention Bitcoin...same idea
<Ian> Manu: Alipay does a lot more than PayPal.
<Ian> ..you can do a lot more like linking to bank accounts
<Ian> ...you can pay credit card bills, etc.
<Ian> ...there are many things that Alipay does...clearly we need to mention it
<Ian> ...we also need to break out the components of ALipay since there's not just one thing that it does
<Ian> ...it does 3-corner model, 4-corner model
<Ian> ...so we should mention Alipay but do so in a way that is specific to the particular function one can achieve through Alipay
Ian: My little bit of guidance
would be - where it's a useful example - look for other
examples in the document and we can add Alipay alongside other
instruments.
... Where we have payment instruments known to other large
markets - MPesa - we should mention the relevant ones - we need
to help international audience understand that this is a global
standard.
... You may be thinking of other things in Asia that are
important to mention.
<Ian> Manu: We don't have anything about Chinese market escrow payments...those are different from many payment scenarios in US or Europe
<Ian> ...so it would be great to have that covered in the document
Ian: We have these phases of payments and we're trying to come up with some narratives that illustrate the different phases in practice.
Ian: In that example, she uses a
credit card - we don't want readers to understand that we're
not using just one type of payment.
... We need additional narratives to show how phases of payment
work in those scenarios.
... For example - here's a common scenario in China - section 3
describes phases and steps... then you write a story on "how" -
using Alipay, using the steps.
<Ian> Manu: +1 to having material in the document to emphasize it is international...with examples from different countries.
<Ian> ...including China, US, and Europe at least
Ian: Happy to read and send in review comments.
<Ian> IJ: I will read it
Ian: One other thing - sounds
like we're converging.
... Labels for alternative use cases... - Freemium offer, email
offer, motiviation will help us explain why there are two use
cases - but what's gone is any categorization of things.
... What's useful about my subheadings - manual selection,
assisted selection, that broke them up into smaller groups -
conceptually easier to grasp.
... When I didn't have good subsections, I put "general" -
variation in delay - added a little bit of explanation.
<Ian> Manu: I thought the categorization of related points was useful, but I have a concern
<Ian> ...we can only have so many headings :)
<Ian> ...maybe the time to make the decision is once we have them all in the doc
<Ian> ...category headings with only one thing takes up space
Ian: Yes, understand all
that.
... All problems can be solved with an additional layer of
abstraction. :)
... Maybe we could do a bottom-up one instead? One-time vs.
Recurring payments....
... What I found useful in adding the headers was to help see
that there is a theme emerging. This was intended to touch on a
variation of that theme.
... That let me see that we covered all the variations on that
theme.
... I found it useful to see if we're repeating ourselves. If
there was a bit that was a theme - "Frequency" could be used.
Or in "Motivation" add a bit that says "relates to use case
XYZ"
... Could be part of motiviation, making that a little longer -
it might be fine to include there.
<Ian> +1 to trying some ideas
<Ian> Manu: So to get to FPWD:
<Ian> - We need use cases for section 5
<Ian> - We need to experiment with the template
<Ian> - We need some real-world stories in section 6
<Ian> ...bitcoin, and an alipay scenario would be great
Ian: That sounds good to me - a lot of work from from you has gone into listening. I'm not hearing objections to the direction - so let's keep going and get it in front of the group.
<Ian> Manu: Alibaba had a comment about not mentioning biometrics/2-factor...we need to get it in there
<Ian> ...DSR has suggestions about exceptions to get in there
<Ian> ...next big challenge will be to get review in a timely fashion
Ian: I'll read it and focus on
look and feel - happy if you are taking the lead on the actual
use cases.
... ... and watching people's emails go by suggesting use
cases... that division of labor works works well for me.
<Zakim> ShaneM, you wanted to talk about agenda
ShaneM: In the meeting announcement - it said this meeting is 90 minutes, you may want to fix that
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Wallett/Wallet/ Found Scribe: manu Inferring ScribeNick: manu Present: KePeng Ian Manu Shane Agenda: https://lists.w3.org/Archives/Public/public-webpayments-ig/2015Mar/0064.html Got date from IRC log name: 12 Mar 2015 Guessing minutes URL: http://www.w3.org/2015/03/12-wpay-minutes.html People with action items:[End of scribe.perl diagnostic output]