(techno music) (audience applause) - Hi everyone! I thought that was a really great introduction, So yeah, today I'm gonna talk about traditional CSS at scale, and if you're wondering what "traditional" means, it basically means "not JavaScript." Love those past two talks, they're awesome, but I'm not gonna talk about CSS in JS, so apologies if you were looking forward to more of that. So my name is Mandy Michael and I'm a Front End Developer. I work for Seven West Media, but specifically I work for West Australian Newspapers and you can find me on Twitter if you like, I Tweet a lot about combining emojis like my sweet monkey, but we're not gonna talk about emojis, I'm sorry. Wouldn't that be nice? I am gonna talk about styling the West Australian though, and that is a news website in WA, and I'm probably gonna talk a little about a bunch of the mistakes that we made while doing that, so that's gonna be fun for you, probably not for me. Just some background though, this is the West Australian newspaper, it's the second-oldest continuously produced newspaper in Australia, and it was first published in 1833, which makes it pretty old, it's like 183 years, I think. It became the West Australian in 1879, which is pretty cool. And these were the first versions of the website, it first came online in 2000, I love the brown one. Not really sure what they were thinking, but the most recent version was maintained by Yahoo 7 over on the east coast, so over this way, but last year the business decided that they wanted to bring that in-house, and so they created a whole new team over in Western Australia. And that came with some challenges, the biggest one being that we had four months to do it, it was a non-negotiable deadline, and in that four months we had to build a bunch of stuff, specifically a public-facing website. We also made a component library to help build that. A content API that had to integrate with the existing editorial tool for writing content for the newspaper, and also a curation tool which allowed the editorial team to manage certain parts of the website.
There was a whole bunch of other stuff, but these were the main focus areas.
And that's kind of a lot to do in four months, plus build a team.
So then on the Cobase we used Node on the back end, react on the front end with Webhack, and for our styling, we primarily used SCSS. Or, I'm gonna call it Sass because it's easier. But I think when you're thinking about writing CSS on large projects, it requires a lot more thinking than just the solution that you use to write codes, so it's more about, it's about more things than just "am I gonna write it in CSS or JavaScript?" Sorry, I'm gonna take a few digs at JavaScript but, I apologise.
So today I'm gonna talk about some of those things. Specifically, I'm gonna talk a little bit about styling in a component library, just the stock CSS part. Then a little bit about style guides, specifically code style guides, not component libraries. Linting, and then we'll also talk about CSS but mostly concepts like BEM and Sass and, sorry, post-CSS.
So these are my GIFs to make me feel comfortable as I'm going through because you can't be scared when there's Corgis on screen.
So you'll get those throughout.
I had a joke here but I forgot to say it.
It's "let's dive right in", but anyway.
(audience laughter) So, component libraries, yeah, we built a component library for the West, and the purpose of the component library was to provide us with like a common language that we could work with so we could build better, faster, and a more cohesive experience. And it also promoted readability by breaking down the common design patterns into more individual components so that we could reuse them in other parts of the website and on different products. As a result, we followed a very consistent structure with our components, much like we have seen in the other talks, this is one of our layout components, we do name them after constellations because it got confusing to figure out what to call them, but in each of our components we have test data, a changelog, the component itself which is at the bottom, tests, a style guide which is like the example on any usage guidelines, and then we've also got our Sass file which contained all of the CSS specific to that component. Now if anyone's noticed we do actually use TypeScript with our project as well, so, I can't remember who said TypeScript is awesome, but it is.
Now for our global styling strategy, because there are some things that we want to share, we follow Harry Robert's ITCSS Methodology, and that helps us to create, manage, and scale large CSS projects, and we've modified it a little bit, we don't follow it exactly, as he has, I guess, decided, but this is what works for us.
It basically follows this inverted triangle method where the higher up a file is, the further it reaches across the codebase. So that might be something like a variable. And the further down you go, the more specific and explicit you get with your CSS.
So in our case that would be like a component. And this kind of layered methodology helps to address some of the issues and difficulties with CSS, but it also helps with the people problem, because I don't think we're very good at being consistent, and that's okay, but that's why we have stuff like this. It's basically just a way of thinking about how to write CSS on projects, and it's really simple, so if you're not using something like this I'd check it out, it's great for consistency.
So this is gonna be my first slide of mistakes that we made, so this seems really obvious, don't split your styles between your product and your component library, and I'm sure everyone's like "well duh", but, there was bit of a misunderstanding in our team about the purpose of the component library, and this meant that some decisions were made that were difficult to unwind in our four month deadline. So right now we have styles split between our component library and our product.
And that makes it really difficult to work with the component library and the CSS.
So we're unwinding that at the moment, but it's definitely something that we could have avoided had we taken the time to communicate a little bit better, I think. Also, we test all of our visual changes manually through our device lab, that's really time-consuming and super prone to error, so we're currently implementing visual regression testing, I was hoping it would be in before I got here but it's not.
Sadly, it didn't quite make it.
But I think if we had that we would break a lot less than we currently do, and sadly we do break quite a bit of things. I'm sure everyone can relate.
So anyway, when you're styling in a component library, I think, try and keep your components contained within a component folder but also in the broader sense, in the same location, and follow some kind of methodology like ITCSS, there are others out there but I like that one. And, while automated testing shouldn't replace manual testing, where possible set that up so that you can avoid introducing visual regressions.
So this brings me to styleguides, like once you've got your component library set up that's awesome, but you want to try and carry that consistent structure through to the actual code that you're writing. And I think the word "styleguide" gets a little bit muddied on the internet, I, as I said before, I'm referring to a list of code guidelines that the team should follow when writing CSS, however that might be. And the aim is to keep the code readable and understandable. Basically a common set of rules will help us understand what the code is doing.
So it also helps to make sure you're working together and everyone's heading in the same direction, love corgis. So I'm gonna digress for a little bit here, I think you may be wondering "Uh, this isn't CSS, Mandy", but it's really important to consider the people and how you make decisions, and we like to make a lot of decisions as a team, so one of the things we introduced for specifically the styleguide process was a care factor scale. We don't call it that but I don't wanna swear on stage, so, we adopted it from Andrew Morrison and Etsy, and basically where we disagreed we'd give our care factor, zero is "I don't care at all" and ten is like, "oh my God, "this is the most important thing in my life right now." So an example, leading zeroes, which is basically when you put a zero before the decimal point, I don't really care. They could be there or not, whereas one of my colleagues was quite insistent that we keep them, so we do. Unfortunately, things like indentation, always high care factor on, so we just kind of picked one.
I won, we get four spaces, Luke's not happy about that, he still complains about it.
But you know for the most part, a strategy like this helps people to determine what's important to them as an individual, but also get a better understanding of what's important to the team.
And I think that helps to create a kind of more respectful environment, and it's really good in diffusing overly robust discussions by giving people a way to back out of an argument.
Because sometimes you realise that it's not as important as you thought.
So this works really well for us and in the case of the styleguide it helped us create a style that we were happy to work with, and most importantly, follow. So back to styleguides, we used that strategy to capture all the things that were important to the project and the team and document it in a styleguide.
And this included things like structural files, order of properties, formatting, commenting, indentation. And I don't think the specifics are that important, because it will vary between teams, but the point is that you consider it and you document it.
And if you don't know where to start, there are a heap online, like, Airbnb has one, you can just Google it, you can start from there and make modifications as you go.
So again, we made some mistakes.
Because our team was evolving as we were developing, we progressed without some clear decisions up front, which meant we had a bunch of discrepancies. And this slowed us down a bit during peer review where everyone was "byte shedding" over style. And it introduced a bunch of technical debt, and because we weren't consistent with it we had to go back and change it later, so try and make the decisions early. Also, and this is good advice in general, write your documentation as you go, being busy is not a good excuse.
During our rush, we weren't disciplined enough with our documentation, and this meant that we couldn't easily explain or introduce people to our style, and sometimes we'd forget what we decided on and that would be really frustrating because everyone would argue over what we agreed on.
Just do it up front.
And this, this is a weird one, but it's probably the biggest mistake we made in the whole project, and it was not creating a shared vocabulary for our style guide.
Basically, newspapers have a bunch of preexisting language around certain pieces of content, so there was a lot of misunderstanding over the differences between an abstract, a teaser, a summary, a headline, a header, and a heading, and when and where to use each one. So we made a bunch of mistakes around this, and there was so much communication within the wider business, miscommunication, that I wish we'd worked that out earlier.
And we are going through this at the moment, like, to bed it all down, but, if you can do that, do it up front.
So when you're creating your styleguide try and capture all the things that are important and if you can, include the team because you want them to be on board with it, and document the decisions as you go, and any changes that you make should be documented straight away, don't delay it.
And then, as I said, creating a shared vocabulary is really valuable, especially if you're inheriting language from an existing business.
So having a styleguide is really great, but enforcing it is way, way more important. And I think this is where it starts to get difficult, right because you don't want people to be reviewing every line of code for spacing and indentation. So that's where Linting comes in.
And it's so easy to set up in most code, and it is, it's a really quick win to improve productivity, and also confidence in your code.
So basically by checking all of the basic rules we set in our styleguide and picking up any syntax errors before reaching peer review, we can increase the value of the code review by allowing the team to focus on the implementation rather than the style. I also found, like, being forced to follow a standard improves your ability to write good code naturally because you're not gonna faff about having to fix a whole bunch of errors that come up.
So we use, like, a couple of tools, we use CSSComb specifically to arrange our properties functionally. Now why do we bother doing this? It's just a good way to organise your code, I don't like to do it alphabetically so we do it this way, and we group things by layout, or Box Model, or visual. It's really useful when you're trying to figure out something that you've stuffed up, because you start to expect certain things in a particular spot, so it's great. And we also use SassLint to keep our formatted code to match our styleguide.
I find inline Linting really satisfying because as you fix everything, like all the errors disappear and it's like a win as you're going, it's super fun. This is VS code, I love VS code.
Total side note, but I changed to VS code on the 19th of October last year, best decision I ever made, sorry Sublime.
VS code is great for TypeScript also.
So actually, I was trying to figure out a mistake we made with our Linting and we actually have really good Linting, so it was really hard, but what I would say as a piece of advice is it works great to have it in line, if you can integrate it into your build process, that's way better.
We did have this but we didn't do it early enough, and it would have been great to catch some of those kind of YOLO, midnight mistakes that we made, especially right at the beginning when we were, like, still figuring stuff out, so if you can do that I would advise. So when you're enforcing your Linting, make sure you're checking for as much as possible in your styleguide, you want people to be focusing on the actual implementation and not style things, and integrate inline in your code editor like VS code or whatever, and your build in deployment as well.
So finally we're like, most of the way through and I'm gonna talk about CSS, sorry about that.
When we talk about CSS, though, we aren't really talking about CSS anymore, I think, like, usually a combination of actual CSS and then preprocessors, or PostCSS, or maybe CSS-in-JS like we've heard about today.
On the West, right now, in production, we actually use all of these things to write our CSS, including CSS-in-JS, which is something I will talk about later, I apologise, I said I wouldn't talk about JavaScript.
But I think, when I put these slides together I realised how much the landscape of CSS has changed, and how we've created a bunch of tools to help us write better CSS.
But I find it really funny that for something that's considered easy, there's still so much, like, misunderstanding and confusion exists around it, like specificity and cascading inheritance. And it kind of results in this situation where people become afraid to touch it and they just start adding stuff to the end. And I think this fear and misunderstanding of the code base results in really bad practises, like adding new rules to the end of a file, or difficulty finding overrides and managing specificity, and just generally unwieldy and hard-to-manage CSS. So a couple of years ago, I made this Batman-themed CSS specificity website, which I thought was really funny at the time, but when I look back I think, "If I need Batman to explain specificity to me then "this is clear that CSS is a struggle for me", like this Corgi trying to climb up the stairs. So I think that's why we have things like Sass and BEM and PostCSS, it's to help us manage those difficulties. So I'm going to talk a little bit about naming conventions and Sass and Autoprefixer before we finish up. So firstly, in our codebase we use we use BEM as our naming convention, and that helps us solve any issues we might have with global scope.
And if you're not familiar with it, quick refresher, a block is meaningful on its own, like a header, an element is part of a block, so it has no standalone meaning, like header title, and a modifier is like changes to appearance or behaviour, and that might be like, error, or active, or open, or something like that.
And it tells us how classes relate to each other which is really useful in more complex pieces of code. So it was kind of talked about a little bit before but we use BEM to help us identify relationships with the top level component, and because BEM's not strictly tied to the DOM we don't need to replicate the DOM tree with BEM so in this case, card title, which is part of card_header doesn't need to be card underscore underscore header, underscore underscore title, which gets really yucky and this is one of the things that I think people hate about BEM but you don't have to do that, we don't, if everything's scoped to the top level.
Actually, Mark mentioned this before, one of the biggest issues with BEM is that you're trying to figure out what to name something, but when you're working with components, a block and a component are the same thing. So whenever we'd start creating new blocks inside of our components in React, then we just create a new component instead, and this is a really useful strategy to follow when you're working in a component library. And in addition to BEM, we also use Namespacing for things like JavaScript hooks that we use for, like, sadly, third party advertising.
And then, like, behaviour and state we'd use .is or .has or .can, which we also use for our React props so it's nice to carry that naming convention between the projects, the code. And I think in this case Namespacing helps us to understand what certain classes are doing, but also gives us confidence in removing things, so if we get rid of a bunch of JavaScript, then we know it's okay to remove that JavaScript class and we're not going to break any of our CSS. But I guess the catch there is you should never put CSS on a js prefix class, otherwise what's the point? So when you're implementing your Sass, use your naming convention to help inform your component building blocks, and I guess vice versa, and if needed, use Namespacing to create clearer classes so you can understand what you're doing.
And most of all, be consistent, because naming conventions, as others have mentioned, are really not very useful if you don't stick to it and it can fall apart really quickly. So now I'm finally gonna talk about Sass.
We do use Sass, and I think, as much as I love CSS, things like nesting and variables and functions and stuff are invaluable for creating maintainable codebases. And it's a key indicator, I think, of why preprocesses have become so popular. You may be wondering why we didn't use CSS modules or something else because we're using React In. Everyone does that now, apparently.
Look, the completely honest answer is it wasn't necessary and we didn't want to risk delivery by getting stuck. The team had this, like, we had a solid understanding of Sass and we didn't think we needed something new to deliver the project, especially in such a short timeframe. And you know what, we didn't.
Preprocesses fit into component base development totally fine, the process is really simple, you have your global styles with the ITCSS Methodology that I talked about earlier, but then each component only contains styling specific to the component, styling of different modifiers and states, and then, when necessary, styling of children or siblings. You don't really want the styles from other components leaking into your component CSS, so it's really important to follow that.
We also make the most of variables to improve our consistency for things like colour, margins, fonts, and those things we store globally, but it's important to make sure that you don't allow any hard-coded values into your CSS because that will compromise the effectiveness. And then of course we use mixins and functions a lot, I have a special affinity for Mixin because of my conference name but I don't use them that much. And these are really useful for common chunks of code, or to reduce, like, cognitive load for things like converting pixels to rems or ems, fluid typography for example, and these kinds of things exist in our global styles. Occasionally you might have local mixins that are specific to a component, and they can stay in the component, like, there's no point in jumping between files just to have all your mixins in one spot.
But I think, like anything, whether it's JavaScript or CSS or whatever, people can get really excited about all of the features and capabilities of things like preprocessors, and the desire to use all the things can be really exciting, but I think, just don't, like, if it makes it easier to maintain, understand, or work with, that's awesome, otherwise just leave it alone. Running complex code does not prove you know what you're doing and it doesn't help you or anyone that you work with.
So I guess it's kind of like with style components, you want to keep it so that people understand, like, don't be a jerk about it.
Now this is my opinion, so I apologise if anyone does this, I think a great example of overcomplication is using Sass nesting for BEM.
I have so many cares about this, like, (audience laughter) I don't understand why people do this.
I love nesting, it's great for pseudo-elements, mini queries, whatever, But this to me is a totally unnecessary complication and it directly impacts readability and searchability of your code, I just wish people wouldn't do it. We don't do it at work, I get really upset about it, so nobody goes there, which is really good. So generally, some advice, I'm gonna reveal some really bad things that we made right now, and firstly, don't use overly generic variables.
(audience laughter) So we actually didn't do this everywhere, but we made some poor choices and I don't think I need to talk about that because everyone laughed, it's obviously not ideal, and we're cleaning it up as we go.
Also, naming things is really hard, so do spend the time to name properly, this is our greys, grey dark, light grey, grey grey, I don't know, actually we named them after animals, so, (audience laughter) I didn't actually know an Ermine was a thing until we were looking for a whitish animal, so we do this and it's a really great reference point, I know that Gorilla is the darkest and Ermine is the lightest, and we also in our variable names prefix with grey so when we type grey in our code editor we get a list of all of our greys and we can just pick the animal that we want. So I guess in summary, make the most of the features of the tool that you're using, whether it's variables, mixins, functions, but while it might seem like a waste of time, spending time on naming and thinking about what you're doing is really important, even if you're busy. Yeah, anyway, let's move on, I feel really bad about that padding thing. So I'm just gonna quickly mention PostCSS.
You can replicate a lot of preprocessor features with PostCSS, but we literally use it just for Autoprefixer. And I find it really valuable, specifically for Flexbox. I don't think I need to explain that.
Obviously, writing that is really not fun.
I actually had to remove some properties because they didn't fit on the slide, maybe I should have left them in and it would have proved my point. So I don't really have anything to add about this, other than I think Autoprefixer is awesome and everyone should use it.
It makes testing across-device really easy. So, I'm nearly finished, we're reaching the end. But what I did want to say is that you might call this stuff traditional CSS, but it's really about writing consistent, maintainable CSS, rather than focusing on a specific solution.
And if you were paying attention, you might have heard me say that we do use CSS-in-JS in the West right now, and I conveniently skipped over it. So we do use CSS-in-JS now, we didn't at launch, we used glamorous JS, it's really great, it's very similar to style components, I'm not going to go into the benefits because we've also already heard about why, but for us it's a lot to do with our React native app. We're also doing a lot of theming and we're experimenting with it as a tool, so it does exist for some components. But to be honest, for me as a CSS person, it's not really any different, like, the majority of strategies I've talked about today haven't really changed, and hasn't affected my day-to-day that much.
I think that whatever solution you use or combinations of solutions you use, it doesn't negate your knowledge of CSS, or all the work that you do in setting up your styleguides, your processes, and your structures. These foundations that you build on and grow with over time, they are what help you to style at scale, all that knowledge doesn't disappear.
And when we decided on implementing glamorous after some experimentation, one of the first things we did was set up a styleguide. In fact, the styleguide used a lot of the stuff we had for our previous CSS styleguide, so those kinds of ideas, they're reusable, right? You don't have to start from scratch every time. But I think what's really important is not being afraid to change.
Working in a media industry is really interesting. They're in a challenging time at the moment with Fake News, and, you know, trying to be relevant in an online space, and I think they're often criticised for not adapting to the demands of their users, and while I was writing this presentation I realised that CSS could easily fall into that same boat.
Much like the media industry, I think we need to adapt and change and evolve, and whether that's by improving CSS as it is, or making the most of new tools, I think it's a really exciting time for us. We've never had so many open doors and opportunities with our styling, and I think that's just super exciting, it's like external style sheets all over again. But what's most important to remember is that for people who love CSS and people who want to style the Web, our foundations don't change.
What we want and what we have is this kind of, I call it a Styler's Code, and that's to produce understandable, performant, and maintainable code. And most of all we want the output of that to be usable and accessible, and result in a well designed website. Whether we use traditional approaches or not, it doesn't really matter, many of the strategies I've talked about are relevant and useful regardless of whether you write CSS or Sass or style components or glamorous or whatever comes next because there will be something else. I think it's just our challenge is to make sure that when we make our decisions for styling, especially at scale where, you know, all the problems are magnified, that we remember this code and we make that our driving force for decisions, rather than the specific language that we use to write it. So that's all, thanks very much.
(audience applause) (techno music) $%^&Marcos Carceres Using the Web Payments API.srt#$%^
(techno music) - [Narrator] So there's a little bit of a theme now with the past, present and future or current. You know. So, let's get into payments. A little bit about payments.
So we've been doing payments as humans, like transacting for a very long time.
So, we kinda have an idea of how we actually do payments. So I'm not going to bore you with a whole bunch of economic theory and contract law and so on. But, needless to say we know the basics of how to pay for stuff or how to buy stuff.
And also over the last 25 years the web has really facilitated that e-commerce, Let's call it e-commerce movement.
We know, we get it, how it's supposed to work. So, what was fun, writing this talk was let's look at the past stuff and then it turned out that the past is really like, now.
I will show you why, particularly in browsers. We've had for a long time now HTML 3.2, that's going back to, I don't know, 1996 or something.
We've had forms for a very long time and we love forms for a number of reasons.
A, they give us type control, B, they give us validation, they are highly accessible, but it turns out that they are quite annoying to fill over and over again, particularly on mobile devices, I'm sure we can all agree with that.
But, we've used them effectively for a very long time, the model is there and they also support obviously posting to the network as well, which allows the safest data. Or we can also store it locally.
So, effectively, as we understood the problem of forms, which is the one I just discussed about being able to post them, the browser are now there to actually help you with that.
And who's been adding the HTML magic attributes to their forms to get auto-fill behaviour? Yeah, one person. Okay you need to do more of that. Thank you.
That's a start, that's also what I mean by the past and the present kind of now. So, if you're not doing it
right now, then get into doing it.
It's very simple, you just have auto-complete and then you can say cc-number and so on.
And you'll get instant behaviour.
Let's see auto-fill in action, and we've only shipped this in Firefox very recently, I don't even think it's in stable yet. So, this will ask the user do you want Firefox to help you fill forms? If the user says yes then it's enabled globally. And you'll start basically getting information for free. You can store multiple profiles of information, and that will fill in forms, yay! So no more typing or not as much typing.
You've all hopefully experienced that on websites. So, as developers, add that it really helps users. This is fine, problem solved, let's all go home. It's not fine.
So, let's go to the present now and the present where we can look for present technology or things that are being solved presently in this space, we can look to our faithful leaders, Microsoft Wallet, does anyone have a Microsoft Wallet account? You might, who has an X-box? So, one person.
I'm sure people have X-boxes right.
So you secretly do have one.
If you have some kind of Microsoft account you secretly get a Microsoft Wallet.
It's already like... yeah. (laughter) No, this is important, this is gonna be important, who's using Apple Pay? Yeah, so Apple Pay is amazing.
A real motivator for this work is actually the work of Apple which we'll get to in a second.
And what about Android Pay? Not as many as Apple but pretty good.
Already as you see, a significant percentage of the people here have these technologies.
Even if you didn't know about it like the Microsoft Wallet one.
So you might actually have that if you have entered your credit card details or given them to Microsoft at some point.
Apple, who's used in Safari, who's had the privilege of paying on the web with Apple Pay? A couple of people. The experience as showcased here is pretty amazing. You can use your phone and using the biometric scanner you basically authorise a payment.
So this is really quite revolutionary.
And there's also a whole bunch of crypto that a merchant needs to go through in order to get on-boarded on to Apple Pay.
There's all this fraud proofing stuff, they've basically solved credit card fraud because it all goes through Apple's network and there's so much encryption, so much of this heavy weight stuff that it needs to go through to actually make a payment with Apple pay. On the web, we got a little bit jealous, like, hey them Apple folks, they're doing really good stuff. Microsoft and Google and Facebook and more Google and myself and a bunch of other people we all got together and we put together this API for you all.
Which is the one I'm going to show you how to use. Who's missing from the list? (audience chatter) Our friends, Apple, they announced last week, hey that looks kind of interesting, we may consider it for a presentation. We are super happy that they may or may not implement it but they've given positive signals.
(audience laughter) But we've been super, like we've based the whole API on Apple pay, we've been super, super accommodating to everything that they need.
So hopefully that will know entice them to actually do this. Let me show you just to get an idea of how this actually works.
Here's your regular shop, so you could go, I want to buy one of these and I want one of those and then you go to checkout and instead of showing a form you let the browser take over at this point.
What I'm showing here, keep in mind is just a prototype, this isn't the final design, this is all gonna change. Essentially, the user will be able to see their items that their buying, they'll get an idea of the total. They'll be able to select the shipping method, and also what payment method they want to use. I'm gonna show you in the future you'll be able to choose a website here.
You'll be able to choose Paypal or whoever. Alipay, it doesn't matter.
Right now we are going to use what's called Basic Card, auto-fill kicks in, boom, so it's already in the browser so it knows me, the card number is now.
Let's do it.
(laughter) If you're testing, I found the testing numbers so you've got a 4 and a bunch of 2's.
Anyway, I won't waste time on those.
But there's a whole bunch of credit card numbers that you can find.
And then the CVV which we will not store.
We store all this information encrypted.
Save that and then pay, processing, this then gets sent back to the website.
Boom. It went through, done.
Are you going to heckle all the way through? (audience laughter) On the second round here, let's give the network a little bit of time to catch up.
That's all right. Let me show you also, while that's loading there.
Just so you can see that it's not just in Firefox. This is in Chrome Canary right now.
So it's similar payment form, it already has my details, one-click, pay.
One click, type in your numbers, which we will not store obviously for privacy and also for security reasons. And, that would actually work.
So the reason it's just sitting there processing is that I'm faking the thing and it's supposed to say, yes this payment has gone through.
Which is what I'll show you now. Cool.
It's already in Chrome mobile as well.
So the network is not being too terrible.
So you just check out again, the experience for mobile comes up from the bottom, it's already fully integrated with Android Pay as well. So put in your CVV, boom, credit card verified, payment being made, done.
It's super slick, super fast, no more annoying users with having them type in annoying things.
So this really changes the commerce model because now you don't need to have them register an account, you don't need to make them go through any pain. You can just put a buy now, click here to buy thing and they can just go through this shopping experience which is kind of cool.
Let me talk a little bit about the API.
The API is essentially, I should have gotten the laser but I didn't.
It's essentially a new payment request.
Yeah, that's what I want, okay.
And you have this method data, the details of things being bought and some options as well. Methods, if you think about it, so how do I pay for things? Details, what is actually being purchased.
And the things that you actually need finally, it's called the options, the things that are actually needed to complete a transaction which I'll show you now. Let's start with the methods.
Like I said, we support cards, so we've been working with all the credit card companies. And essentially you can say I support a debit card or I support a credit card and I support Visa and Mastercard but I do not support AmEx for instance.
What this allows the browser to do is say, hey, I know my user has a Visa so I can automatically just match that up and say look, they supported this and just kind of highlight that and make it a thing of choice. Another thing that we're doing is, like I said, we are trying to integrate websites as well. You can say your supported method is, for instance, https://ansaid.com.au/pay, something like that.
This is more kind of looking into the future. So now for the details, so let's say you're doing an invoice, you might add an ID and then these are the items. The display items are pretty critical, don't leak, the browsers will not pass this information on, but I'm just telling you now, don't put what people are actually buying that's a real privacy problem.
Don't say, oh they're buying underwear and they're buying I don't know.
Don't reveal what people are buying, they are buying clothes.
The clothing that you're buying is this.
So that's pretty critical.
Currency support as well, and all you need is the total. That's the details of the transaction.
And then there is the options, so you can say what kind of shipping as well. So you can have like standard shipping and then you can have like drone shipping if you're like Amazon or something.
When the user goes to select what kind of shipping they want you'll get an event back.
You might say we support these three kinds of shipping but I actually can't ship to, the store might be in the U.S. but I can't ship to Australia which is a very common experience for us who live here in Australia.
In that case the webpage or the merchant gets an event and they will deal with that event saying look you can either ship here or you can't and you can update your shipping options based on where the person or where the user is.
And that's done essentially here with this update with new details.
If everything goes bad it's like sorry, we can't ship to your address.
So it allows you to display an error message as well. And then there's this weird case which we've all experienced like we've gone to a restaurant and you go and pay with a credit card and it's like well, if you're going to pay with your AmEx, you're going to have to pay 3 percent more.
But if you use a Visa and if you happen to have the Amazon Visa we'll give you a free mug or something like that.
So, we can model these kinds of situations as well. So we could have like a food card processing fee. And, so again, basic card, you slap that all together in this giant object and you basically send it in. Payment options, finally, these are like the things that you actually need to complete the transaction. Here you can request the user's email if you need it, the name.
So obviously if they're buying a digital good like a movie ticket or something like that where you can just have a barcode you're not going to need a shipping address. You can turn that off, they're all off by default. Essentially this is the flow.
If you saw, we did a show that returns a promise and eventually you'll get back a response.
Then we can validate, we'll get back that data, you're not guaranteed, see you'll request this stuff but the user may be like, you know I don't want to give you my address for whatever reason or maybe I didn't import my email. The email that they might have saved might be wrong. So, it's still up to you to validate the response. We'll do some validation.
This may also include, okay, can I actually ship this? Actually the shipping would have already happened. Can you actually complete this? Or you might actually, now that you have the response, the response has the credit card information so you might actually then send it to the server and say look, can they actually pay for this thing? Do they have money in this account? So you might get at that point a success or a fail. If you've checked everything and everything looks good then you can complete with success.
Otherwise, you can say look, I can't do this transaction. Or they might be on a train or something and the whole thing may come crashing down.
So, you're order's complete and done.
Let's go in to the future a little bit.
The future's already here just not evenly distributed. There are new ways to pay for things.
Who has Bit Coins? Maybe, one.
Some people are already getting like Bit Coins. Other things that are already there is that there is more than just credit cards.
There are people who want to transfer money around the world and so on.
How to we bring those companies on board? A lot of these payment handlers already exist as native applications.
What we're also doing is allowing integration with Android as well.
This is very small.
This is like just Android manifest for anyone that does Android development.
So you can integrate.
And we can basically say, this website alipay is actually linked to this native app. And then that will allow the native app to actually take over this payment processing and you'll actually be able to pay with like alipay or whatever using the native app. So of course then we get web envy again, So we're like oh that's not like, we need to let the web do this as well.
Ideally what we're working towards now is assigning a new API which will actually allow you to do this. And this is the payment handler API.
I'm not going to show you the details because I'm still working on that API and I'm changing it a lot together with people from other organisations.
But essentially it gives us a coherent story now. We now have, we will have the ability to pay with things on the web.
We'll be able to use native apps to pay and we'll be able to just use websites.
Or we'll let the browser take over with auto-fill. It completely opens up the eco system, doesn't discriminate against anybody and it also starts including these new proprietary payment methods such as Apple Pay and so on.
So tokenized payment methods will be coming, like BitCoin as well.
This will probably change.
We've kind of worked out that we can do this without a permission model but it might be that you go to wallet.com and wallet.com will be like, hey, I can handle payments if you give me your credit card info.
Imagine Amazon already has your credit card info so it might just go, hey, I can handle this stuff for you if you want to make payments with me.
And then it will be able to hold wallet, it will have a wallet and it will be able to hold credit cards or other payment methods.
And these will all be eventually driven by a service worker, which will have a single event which is like on payment request and then you do your magic, whatever it is, and you'll be able to drive the browser's user interface with that and allow people to pay more easily using a very diverse set of methods.
Chrome is currently prototyping this, together with PayPal so they announced that at IO. So we should see the outcomes of that pretty soon. And that's it, that's the web payments ecosystem. So we take forms, we take auto-fill, we have payment requests coming into the pipeline now. And eventually we are moving into payment handler API enabling crypto currencies.
So we're looking at ten years out.
And that's all of web payments.
Thank you.
(audience applause) (techno music)
