In this 2020 review, we've pointed to a few areas of astronomical research that need a better look with a telescope larger than Hubble. These include exoplanet formation exploration, like finding out what happened to Fomalhout B, star and planet formation in places like the Trapezean cluster in the Orion nebula, the age of stars in the Milky Way central bulge, and the search for first-generation population three stars, just to name a few. That telescope is the James Webb Space Telescope. It is almost three times the size of Hubble. It has been in development for over a decade and is scheduled for launch in 2021. It's optimized for observations in the near-infrared. We'll cover its key components and where it will orbit. We'll finish with a deeper look at two areas of investigation that Webb will probe, galactic dust and the makeup of the early universe. Here are Webb's primary and secondary mirrors. The primary is the size of a tennis court. This animation shows the light path through the telescope. The light reflects off the primary and is focused onto the secondary, where it is beamed into the camera. These mirrors are covered in a microscopically thin layer of gold, which optimizes them for reflecting infrared light. Other key components include the cameras, the sun shield, the solar panels, communications antenna, the computer and spacecraft control. The sun shield is particularly important because of the telescope's extreme sensitivity to heat. Webb primarily observes infrared light, which can sometimes be felt as heat. Because the telescope will be observing the very faint infrared signals of very distant objects, it needs to be shielded from any bright, hot sources. This also includes the telescope's own electronics equipment. It operates at 233 degrees below zero Celsius, that's minus 388 degrees Fahrenheit. That's cold enough to freeze nitrogen. The shield can protect against temperatures on its hot side as high as 85 degrees Celsius, that's 185 degrees Fahrenheit, a little under the boiling point for water. If either the sun, earth or the moon are on the cold side, the telescope won't work. So to have the sun shield be effective protection against the light and heat of the sun, earth and moon. These bodies have to all be located in the same direction. This is why the telescope must orbit at the L2 Lagrange point, one and a half million kilometers from earth, that's one million miles. You'll recall from our coverage of Lagrange points, in our How Far Away Is It segment on the solar system, that objects can, with a little assist, orbit L2. This animation shows how this will work. To remain in orbit around L2, Webb will have to periodically burn small amounts of fuel. This puts a time limit on the usefulness of the telescope at around 10 years.


Gastroenterology. Gastroenterology is the branch of medicine focused on the digestive system and its disorders. Diseases affecting the gastrointestinal tract, which include the organs from mouth into anus, along the alimentary canal, are the focus of this speciality. Physicians practicing in this field are called gastroenterologists. They have usually completed about eight years of pre-medical and medical education, the year-long internship if this is not a part of the residency three years of an internal medicine residency, and two to three years in the gastroenterology fellowship. Gastroenterologists performed a number of diagnostic and therapeutic procedures including colonoscopy, endoscopy, endoscopic retrograde cholangin keratography, DRCP endoscopic ultrasound and liver biopsy. Some gastroenterology trainees will complete a fourth year although this is often their seventh year of graduate medical education in transplant hepatology, advanced endoscopy, inflammatory bowel disease, motility or other topics. Hepatology or hepatotopyletary medicine encompasses the study of the liver, pancreas, and biliary trep, while proctology encompasses the fields of anus and rectum diseases. They are traditionally considered subspecialties of gastroenterology.


So hi, my name is Maria and I am an interaction designer and my talk is called designer developer collaboration test practices. So I have a quick agenda for you guys. We have just like 25 minutes to go through the whole thing. So I'll touch a little bit on the graphic design and then on UI UX design mentioned several unit agile practices, processes that we have, processes we want, some tools that designers work with like I mentioned, I'm a designer and I'm here basically at developer conference. So I will want to give you some insight on how designers work, how it's done with distributed teams, different sized projects, and maybe also mention briefly some open source design practices and communities. So why am I doing this talk basically? As far as I can remember, as long as I've been working with open source with Fedora and Thread Hat, there's always been some issue collaborating with developers, first of all, because developers have different processes. Oftentimes the teams are set up so they are agile, so they're working in sprints and developers have their own tasks and they have their own statuses for these tasks and they do not always match whatever designers are doing. And also I've been a long time contributor for Fedora and as you know Fedora is in many ways working, distributed all over the world. So the people who contribute to Fedora can live in Australia, in the US anywhere, Europe, India, you name it. And it's also always been a challenge collaborating online and now in COVID times obviously many teams are online and it poses much more challenges that way on how to, for everybody to collaborate even if you know developers and designers work in different ways now there's an added challenge of doing it remotely. And from my point of view, better understanding between the two, I don't want to call them teams, but the two different professions will lead to better collaboration and greater results to be out for you, for yourself and for your users in the end. Okay, so hopefully you will get some insight into designer work, what's UIX, graphic design and for the dimensional ready tools, processes and tasks. Okay so let me talk a little bit more about who I am. So at the moment I'm working as an interaction designer, I've been a tractor for six and a half years and I mostly focus on products that are working inside of Red House, so some internal tools. But also I've been a long time contributed to Fedora and I started as a Fedora design intern, so working on a Fedora design team for I think seven years now and I will start at that because I started as a graphic designer then slowly transitioning to be a user experience designer or an interaction designer if you will. So I will start a little bit about talking a little bit about the graphic design process. So in Fedora design team we use a ticketing system and it's on beggar and we have a specific place set up for it so it's beggar design issues and the issues come in here. So if you want to request anything from Fedora design team, so something Fedora related maybe you want a logo, maybe you want some swag, maybe you want a banner, anything that's you know graphic that would go in there. So the ticket comes in, it's triage, so somebody looks at it, it's assigned to a designer, designer works on that issue so they create some design for you. Then there's a feedback from other designers, we do hold design meetings I think once every two weeks at this moment and then we also like to get some feedback from the requester obviously because if you requested the design you know what you need and we would like to hear from you once the design is created because normally the designer when they work they do not just create this one design well I shouldn't say normal but sometimes they would create one design that they think you requested, one design maybe that they like, maybe something else comes to their mind they want to you know as a professional to offer that to you and we would like to hear from you to basically get some feedback. Then based on the feedback they would iterate and once the design is approved you're done. So graphic design process is pretty linear so you get a ticket, you work on it, you're finished and you're done because you get something tangible in the end. You get a logo, you get an icon or a set of icons, you get a wallpaper for that matter like Fedora wallpaper for example is something we work on. Once it's done it's you know done. Alright so the tools that we use and on the left here I mentioned the tools that Fedora uses for their designs and on the right I also mentioned some paid tools if we are not talking specifically about open source projects but rather any sort of graphic design. Here I want to point out specifically a figure that we start ticketing Inkscape that's a great vector tool to work with vector images and vector graphics. If you're editing some photos you would want to use GIMP. If you're working on something more complicated maybe some interface or website you could possibly use panpod and that's something that we started to use recently and the all the talking right now chatting happens on matrix or element and also is mailing this and at some points GitHub is used to store some graphic work. Okay so some of the challenges that are here that we face working with developers is sometimes people ask us for the wrong thing so something that's not in the capacity of the design team for that matter maybe it should go to marketing or some other field or sometimes incomplete information at the ticket because for example if you're requesting a logo you cannot just say okay I need a lot of logo for my team or my project we would want to know something else like who you are what your project does do you have any idea what it should look like maybe you also would be welcome to leave a lot of feedback because it sometimes happens that the designer would create something and then the original requester would never come back to the ticket and they would not leave anything what they like what they don't like or anything like that sometimes they would do with feedback but it can be outputting so be mindful about what you write some of the contributors can be very new a lot of people like to try out their design skills in the design team so you should be more guiding not outputting when you're writing something in the ticket so you should be mindful that those people are volunteer workers that they could maybe you would not be able to handle all of your requests or maybe they don't you know they only do it in their free time and so they won't have they would want able to be I'm sorry they won't be able to do it very quickly anyway some of the advice and just generally working with the global team of designers and ticketing system is to have well-defined well-documented tasks and maybe some you know resources available but that's mostly for us not for the developers for the developers that would be you know know how to submit requests and here I'm saying developers I generally think everybody who needs something design created right so be mindful what types of tasks you're considering for the design team think about what info you might need from you or be there to answer questions should we need more and like I mentioned so you know so the time frames can be longer because people are distributed people do it in their free time they might have there you know the main job and they will just you know do some Fedora design after hours and the most important part is to my feedbacks always remember to be there to answer questions to provide feedback and also maybe hard but sometimes it's needful to trust the experts or trust the designers that are working on your project probably they have a good perspective on what they're doing okay so going on from there that was a little bit of an intro into Fedora design team I'm gonna go on and talk a little bit about he acts so he's experienced design and he is an attraction sign so he acts is more of a broad term that sort of incorporates UI in it because he acts is something that we're talking about when we talk about experiences and so if we talk about he acts design it's a lot of things in one so it's testing it's writing user stories it's creating personas doing research writing scenarios creating wireframes creating prototypes whilst UI is mostly concerned with interfaces right so it's mostly about how that looks not how it feels so all sorts of layouts colors typography and it's important to remember that these two need to work together because as you can see in this picture somebody designed this road to go this way right so somebody designed this park I think but then the user experience is completely different so they didn't you know look at the user behavior prior to designing this and this is it in my head the main difference and something you need to always consider that you should design based on whatever people tell you anyway there's a quick representation of what I was talking about so this is yes and this is UI right here okay um going on to the whole collaboration I'm still leading into that um I want to touch briefly on how UI and he acts design is different from graphic design process so as you saw the graphic design is very linear so you get a task you work on it as a designer and then it's done and you you are done the main thing here is that you never really done and then you should also collaborate throughout the process not as a request comes in you do it and you ship it off you know ideally a good UI UX designer depending on what they do will be involved from the start so they will be involved in the strategy in this search they're working with developers from the very start working with product owners with QI with everybody and they should be sure they're solving the right problem so the user has also to be involved from the very start and the good UX designer would advocate for the needs of the user from the very start some of the tools that are used here and I want to mention the tools because it's very important that not only designers try and understand how developers in the end put their designs into life so it's good for a designer for example know some code to know maybe some html by 6css at least when they are working at the book cups to ensure that they can be done or at least work with the developer from the very start to you know ensure that the mock-ups are visible that they would not have to change their design drastically or that they've not designed something totally crazy that can not be done in the end I have to redesign it okay so the tools are so some designers start with pen and paper some can use a graphic tablet to draw their stuff very basic at first then they can use inkscape or sketch which is a commercial product that you have to pay for to put the wireframes together here's an example of a very basic design so it's very you know low fidelity mid-fidelity wireframe this is more detailed wireframe and from there you can test already at this point with your user or it's with someone on your team maybe one or two people you can show them get their feedback see if you go in the right direction specifically the developer needs to be involved at this point already so they can see okay so this can be done this makes sense maybe that doesn't make sense maybe that interaction won't work in the end rate and then you could use other tools like sketch for example or gun pot which I mentioned already or figma or anything else there is a lot of them to put your detailed prototypes together and the important part here is that they would be interactive so you can assign specific parts of your prototype to be clickable like this button if you click this button it does this because oftentimes you cannot just hand over and finish design like you put in graphic design so okay here's the picture and you're done no you have to design the whole experience throughout so when the user does this this happens this this screen appears when the user does this that screen appears that kind of thing some of the challenges here are pretty much the same as we mentioned before but also sometimes when there's no clear understanding what the goals are or who the user is or there's no clear direction then the team can steer off in a little bit of you know wrong path and start designing that way so you need to always check back are you solving the right problem get to the bottom of it get to the user ask them is this right is this right for you um again here I mentioned sufficient feedback so a design does not happen in a vacuum you always need someone to bounce your ideas off of to make to make sure it makes sense maybe if you're designing interface somebody has some example that you could use maybe to have a better idea than you that you could put together and that's totally fine one of the most important things is to design a handoff and specifically I want to mention this because sometimes it so happens that the person design something they will design an interface they would give it to the developer and think okay that's it ideally no because when the developer starts putting it together many things can happen they can put it together a bit differently maybe they don't understand what the interaction is it's not easy to document interactions and it's not easy in the distributed team that matter to explain something I always say that it's easier to show once you know to explain in in two pages of text how the design works so you would want to you know design something and then work with the developer show them explain to them hopefully if you can talk to them if you can video chat them at least to do that and also it can be difficult because people speak different languages so designers have their own jargon developers have their own jargon and it's going to be challenging to understand each other so some of the solutions listed here also I want to mention this third bullet here maintain contact with team members throughout and that means that the distributed team would don't often see each other maybe in some team meetings or maybe not even ever and it's hard to understand how the person you're working with likes to work how do they like to get the work to them for example some people would like it if you would talk to them a lot if you would call them from time to time or maybe if you would other people would like it if they you write the messages or if you email them everybody's very different everybody's process is a different some people would like to check in with you all the time some people would ever do that and one more advice would be to just maybe set up a video call if possible with a team member who you're working with and I don't know how many developers are in the audience or there are any designers or maybe some other specialists so I would like to know that at some point but yeah it's very important to just check in with the person maybe nothing even work related maybe just set up a video call and chat about life so you get to know this person better because everybody works differently and to maintain this kind of human contact is very important and another thing I want to mention is the design systems and there was a talk earlier today about design system which I thought was great and I want to mention that I want to mention two more I want to mention pattern fly that is used wisely widely for products and also I want to mention yaksotradhat.com so it's just a site that contains a lot of components that can be used and reused in different interfaces which might be helpful because sometimes for developer if they get a picture they need to know how what's the size of the elements is basically what's the color because the designers can put a lot of thought into that but it's not easy to read from the picture and so just to think this through how you want to hand off the designs how the person who would put them together who maybe a friend and developer how they would work with it some of the tools that I mentioned online they offer an option to inspect the designs so you could see what the size of the element is and how you could put it in code or maybe you could directly copy code from there and that's much easier for everybody I want to also mention briefly here the open design framework this link works but anyway so that's something that the whole team agrees on so that's the tools that's the processes that's how these design tickets are incorporated into developer tickets and their processes and also how maybe the personas are set up for your process let me speed up a little bit because I don't have much time left all right and so I also want to mention all the uniax which is a sort of it's a process that's been incorporated a couple years back and so that allows you to focus on the outcome so not to build the whole product from start to end with a lot of bells and whistles and features but rather build something that's an MVP so the minimum viable product it's core concept of uniax so you build something that's it wants functional reliable usable introduce maybe some emotional design is focused on users tested throughout but it works and and maybe it's minimal but that can be built upon rather than it's just functional and does that okay so what else can be done you also can hold design thinking workshops and here I'm going to do a quick plug-in tomorrow Marie Norden and I are holding a design thinking workshop in the afternoon and you're welcome to come we're going to do some design thinking exercises and don't be put off by the word design it's more of a way of thinking not of designing stuff one more thing is design reviews it's something I like to do on the teams that I work on so I would invite everybody who's on the team and who can come so we can look at designs we can talk together we can see if we agree on what needs to happen and just you know agree on further steps and always people have a lot of great ideas that we could incorporate in the designs later here I wanted to mention that there are a lot of processes that exist like design thinking lead agile anything and unfortunately it's impossible to solve the whole design developer collaboration problem with the process it really really depends on how the team is set up on how the developers work and maybe it can be different for every single process and let me just get briefly to hear a project right because different projects are different sized and so they have different stages something may be shorter something may be longer but you know you have to be mindful of that and as a designer working with a developer you have to be mindful of that too let me go back on second I also want to mention briefly as a closing maybe almost know the ten usability heuristics I will so my slides are posted on uh shed.org so you can download them or you can hop in I don't know so I will be sharing my slides after the talk and I want everybody to be mindful of these heuristics they are very useful I add them printed out so we'll think about them all the time and I think for developers too it should be very useful to think about this too just to you know to give you a user in mind to keep their behavior in mind and help them out when you're building something um also these are some process diagrams that exist and this is ideally what would happen when you're working on a project but it's not always what would happen and here you could see um what and maybe even who is involved at each stage and ideally all the team or developers and designers for that matter would be involved from start to end so they talk together constantly so they can reiterate so they understand so they're on the same page and they talk to each other not forgetting about the user okay so I guess with this I'll close and we'll have a short Q&A maybe you could give me some advice on how to work with developers better because I would love to see who's in the audience today and if you have any questions and let me stop sharing my screen okay oh thanks Maria unfortunately I don't think we have enough time for Q&A we're kind of at the end here so if uh if they want to reach out to you with the questions I'm going to copy the questions from the Q&A but if anyone wants to reach out to you how can they contact you how can they contact me um let's see well I'll be here I mean I've gone in the event so maybe they could message me in chat right on and and you did say there's a workshop coming up where you're going to be there too yes it's going to be tomorrow cool that's right well thanks a lot Maria that was a great presentation


What's up everyone? I'm Kyle from Driving and Vibing and you're watching Road Gear Reviews. Today we're going to be talking about a new app that makes finding campgrounds, RV parks, and free camping super easy. So stick around. So today we're talking about the new Campendium app for the iPhone. And this is an app that we've been waiting for over a year. So we're super excited to finally get our hands on it. Now if you're unfamiliar, Campendium is one of the internet websites we use to find free camping, RV parks, and dump stations. Now there are a lot of those sites out there on the web, but Campendium really has differentiated itself in our opinion because of the reliable internet connectivity input on each RV park or free campsite that they list on their site. So for instance we can be searching free campsites as in Sedona where we are right now and it'll let us know at which of those sites will we get connectivity and what services are connected there whether it's AT&T, Sprint, Verizon, T-Mobile. So that has been a huge help to save us time whenever we find a campsite and to know where we'll be able to get work done or just stream Netflix. So now we'll get on to the app that they have for the iPhone. And much like their website, the app has a lot of great search filters to make finding what you're looking for extra easy. They have search filters for whether you want RV parks, free camping, dump stations, national parks, state parks, anything like that, like most of the campsites, and they also have a filter by price. So you can search anything from free to very expensive. If you're searching for an RV park you can filter those searches down by what type of amenities the park offers or by what sort of discount programs the park accepts like Passport America, Good Sam, or any of those out there. And like we said at the beginning of the video once you find where you want to stay right there in the review it will tell you what the internet connectivity is like. And unlike any other campsite app out there this is the real selling point for us and why we were so excited about getting this app because it makes it super easy to know where we'll get internet connectivity and what type of service we're going to get there. So after all those filter options you can also use this very simple feature in the search bar it lets you search based on your GPS coordinates at that time or you can type in a destination but we really like that it will see where we're at and what is available right there around us. This isn't so important for us for free campsites but it works even better for finding dump stations or potable water so we don't have to travel far and we can see without typing anything in what is available around us. And lastly one of our favorite features is the maps function at every campsite review you'll see the GPS coordinates for that site. If you click on the GPS it won't take you to Apple Maps it will give you an option of what app you want to guide you there. We personally do not like Apple Maps at all because we've been led astray one too many times actually like 10 too many times but we finally learned our lesson and we love Google Maps so with this function we can click on the GPS and then it gives us the option of selecting which map app we want to guide us there. So we always pick Google Maps and it makes it super easy to find where we are going. Overall the Campendium app is very similar to the website just like we wanted it to be the functionality is amazing it doesn't have any lag time that we've noticed yet and that is another selling point because oftentimes we'll use it while we're driving and even if the passenger is navigating it the speed of operation is important to us so we don't miss any turns and so we know where we want to go as soon as possible. I would definitely recommend anybody interested this app is free all you gotta do is go to the app store and download it test it out let us know what you think about it and also let us know what other apps you use to find free campsites. For us we also use Allstays it's been great Allstays has a lot of awesome features that we'll talk about in the future but as far as Campendium I would definitely recommend checking it out and seeing what you think about it. Make sure to let us know what you want us to review in the future because we're always looking for interesting gear and tools to use on the road and thanks so much for watching again this is Road Gear Reviews new videos every Wednesday so stay tuned and we'll see you guys next time later on.


The Village Revitalization Initiative, a partnership of Senator Patrick Leahy, the Preservation Trust of Vermont, and the U.S. Department of Housing and Urban Development brought federal dollars and new life to rural villages across Vermont. Started in 2005, this innovative partnership supported 27 projects in 25 different communities. Grants from this project helped conserve historic architecture, inspired community use, increased viability and livability, and rewarded community commitment. And they did it all in towns that had fewer than 2,000 people, whether opening a shuttered opera house, rehabilitating a village grocery store, or building an active community center. The projects increased the vitality and the beauty of their village center, and a variety of historic sites. Through it all, the Preservation Trust provided technical assistance to grantees, managed to federal grant and helped turn $2.5 million in federal grants into almost $30 million of investments.


All right. So I'm really excited about this. EdgeConf is kind of like the focal point of a discussion around using cutting edge technologies to build amazing user experiences. But I think kind of the elfin in the room is it's great to learn all about all these new technologies. But what about older browsers, browsers that are less capable that cannot take advantage of some of these things? So this session is an opportunity to kind of discuss some of those challenges that we've had for a long time and what we can do about them now. We have a really powerful panel up here. So let me quickly introduce everyone. Over here, to my right, is Shwetong Dixit. He has been on the Opera Develop Relations team and OpenWeb team for a while now, working a lot on compatibility of all sorts of sites, so whether they have willy-nilly regexes that are blocking opera and such. Also a member of the Web Education Community Group and the Mobile Web for Social Development Group at the W3C. To my left, Tamomi Amura. So she has been kind of fighting for the mobile web for a long time, ever since 2005, when she was leading the mobile yahoo.com. m.yahoo.com, yes. Also was using WERFL to great success, trying to wrangle all sorts of kind of tricky little mobile devices coming over there. Worked at WebOS and is now at Nokia. Cool. On her left is Ed Saudin. Ed works for the Government Digital Service. And the GDS finished a just big huge redesign of Gov.uk, a kind of much-lotted progressive enhancement redesign, bringing all of the UK's government online. And they're now continuing to bring more departments online. They've done a really good job presenting the best way to do progressive enhancement and documenting their strategies and methodologies, and also providing a very transparent development process, blogging, documenting guidelines everywhere. Really fantastic job. And our opening speaker, Tom Maslin. Tom is the tech lead for BBC News Visual Journalism and has been leading the client side team for the mobile BBC News team for a while. Has been kind of a sands-based developer, knows browser performance and JavaScript extremely well. And also a while ago worked on the team that built and open sourced the GLODE JavaScript library. So last from the past. All right, cool. So Tom, if you want to take it away, be great. Hi. Hello. And can I have my slides? Hi. Hello. And welcome to the introduction talk, Legacy Clients by me, Tom Maslin. Or as I think this talk should really be called. Yay, I'm so excited. There's going to be five versions of Internet Explorer for me to support next year. I'm 34 years old. Back in my arrogant 20s, I saw myself as a bit of a hand solo, flying around the office, saving princesses' websites, fixing bugs. My job used to be easy. I had four rendering engines to support. And yeah, I also had to worry about accessibility. But right in my code, semantically fixed that. And I also had to concern myself about SEO. But that's essentially accessibility for search engines, right? So my semantic code sorted that too. This was a time when we could all afford to be little hand solos, quickly put insights together. But then in 2007, all that changed when Steve Jobs invented the bloody iPhone. Shit got more complicated. Suddenly, we had mobiles with very slow connection speeds and phones with different size screens, new types of interactions, smart phones started to appear with pathetic little processes, and tiny amounts of RAM that ran my code really slowly. And PPK also pointed out that there was like 100 different versions of Webkits to support. But all of these problems were nothing compared to what was about to wash over us, an avalanche of devices.  Instead, we've all had to become intelligent, clever spots who can balance all of these issues against getting our job done correctly. As developers, this is the biggest problem that we have today, balancing agility, getting the stuff done quickly, versus robustness, getting the stuff done right. Now, in this paradigm that we find ourselves in, it's very easy to concentrate on this issue so much that we forget about boring old issues like supporting IE7 and IE8. I can test in IE8 and 7, using a virtual machine on my Mac, but it's really hard to do. The experience is slow, and the DevTools are terrible. Trying to get IE7 DevTools to do I1 is like asking a wookie that's wearing boxing gloves to wipe my bottom clean. It's a terrible situation that normally ends up covering you in something. It's some bugs I just give up on because it's not worth spending the time required to fix a problem for such a small audience. It raises questions about whether we should actually support these browsers. I'd argue that sometimes it depends. While the challenges surrounding client support have increased, web development itself has become more popular. It's entered the mainstream. Everyone from school children to contestants on the apprentice are now making web pages. And the act of making a web page is actually pretty easy. Build something, look at it in your browser. There you go. It's done. It's very fast. But as I've just shown you, the practice of web development is the complete opposite. It's actually really hard to do right. Anyone can pick up a book or read an article online that teaches you how to make a web page. How to write HTML5 or CSS or JavaScript. These things are hard to master, but they're easy to start doing. What is hard to learn, though, is how to scale your website up from a single user, i.e. yourself, to a larger audience. These things here, they help you to scale your audience, but learning them is much harder. Because to understand these, you have to change the context of your thinking away from what's in front of you. As a developer, I often find myself having to defend these things, but ultimately, the web isn't about these. They're important, but we don't do accessibility for the sake of accessibility, and we don't make sites fast or SEO friendly or work without JavaScript because it's nice. What we're trying to achieve, our actual end goal, is ubiquity. We want as many people as possible to see our site. The web should be inclusive, not exclusive. I mean, nobody would build a shop that only the dwarf from Game of Thrones could get into, right? Shops have doors that are wide and as tall as possible. Websites should be the same. An easier way to think of ubiquity is to call it browser support. When people talk about web browser support, they think, well, how far back should we go? IE6, IE7. In the website versus native apps debate, the reason why website wins is because apps are binary. They either work or they don't. An iOS app works on an iPhone, but it doesn't work on an Android. However, your site will work on both. And even better, if you build it properly, it will work to a certain degree on pretty much anything. It's the ubiquity of the web that wins. So to go back to the original problem I defined, this job is also harder because the problem is continuing to increase in complexity. And we have to balance that against getting stuff done fast and robustly. What we shouldn't do is fight that complexity with ever more complex solutions. People who build responsive websites that are really just a collection of smaller websites within it are creating more problems for themselves. When a problem grows to a certain size, the problem changes into something else. And to survive, you have to change how you think as well. We did that at BBC News. We turned the problem of browser support upside down. Instead of thinking about how far back we should go, we decided to support everything. We call this technique cut in the mustard. The responsive site has a very basic core experience that has a simple layout, is very fast, and is delivered to all browsers. The core experience is good enough to allow everyone to consume the news. On top of this, we built an enhanced experience using JavaScript and modern CSS. It has a complex layout and is very functional. This is only delivered to modern browsers. It's conditionally loaded by checking for the existence of specific features. All the browsers that cut the mustard have great JavaScript and CSS support. They have fast rendering engines and a less buggy. This technique is robust because it supports a massive amount of browsers. It's also agile as you're building the enhanced experience using modern coding practices. But IE7 and IE8 only get the core experience. Now, this might be good enough for you if these browsers don't bring a significant amount of traffic. Or you might decide that these browsers need more than just the core experience. How do you do that? Well, with two ways. We can edit the cuts of the mustard test to load an alternative JavaScript app that is specifically just for IE7 and IE8. We can then cherry pick what features of the enhanced experience we give them, like a two-column layout or video support. We also need to give these browsers better CSS. With mobile-first CSS, IE7 and IE8 only render the smallest view because they don't understand media queries. But with a CSS pre-processor, you can output a version of a site style at any defined width, specifically for these browsers. The panelist, Ed Salden, has already implemented this for the UK government website. And here's one example of how you can do it. Instead of writing media queries directly into your CSS, use this mixing instead. Then make a new SAS file that sets a variable with the width value that you want IE7 and IE8 to render the desktop view to. Import the main SAS file into this, and it will render out an alternative desktop-only version of your CSS into a new file. You should add the legacy IE style sheet into the page using a conditional comment. Now, however, you have to be careful now, as IE7 and IE8 will be exposed to your modern CSS, and there's lots of selectors and properties that you need to watch out for. If you're unlucky, you may find IE7 and IE8 will be rendering your modern CSS onto the page in a way that reminds you of how Donald Trump's hair renders itself onto his head. So to summarize, how do you support legacy clients? I'd say don't think about stretching your code across an ever-increasing browser support list. The problem is only ever going to get more complex, and you can't keep up by making an ever-more complex solution. If you keep thinking like a hand solo, eventually, this problem will get on top of you. Instead, I think the best way to solve this is with teamwork. Use a solid base of progressive enhancement as a springboard for your JavaScript, and treat each feature on your website like an away mission, deciding when to send these agent browsers to the fore. So that's enough for me. Let's chat about it. Very nice. I'm sorry, yeah. Gee, thanks. Thank you very much, Thanos. Great. So we'll go to our first question. Our first question, delivered by Hakim. Anonymous question, why should there be a stigma attached to not supporting older clients? If a developer knows their audience, and they all have the latest clients, what's the problem? I think that should be, why is there a stigma attached to not what, why should there be? So I'll rephrase that. So Shrutan, do you want to take this? Why should there be, why is there a stigma attached to not supporting older browsers? There is, but there shouldn't be. Mainly because when it comes to older browsers, there's a lot of reason to actually support older browsers, because there's a lot of times in which the user cannot update their browser, whether it's because the system administrator doesn't allow it, or because many times the user doesn't know what a browser is. So if you say update your browser, it's like, how could I update my browser? I don't know what it is. So that's one thing. Second things are that sometimes people know what a browser is, they're fully aware of how to update it, but they don't want to. Maybe sometimes it's because they're using a phone and they have a very crappy network, and they might use a proxy browser instead of something which is like a full-fledged browser. And proxy browsers are tricky, as we'll see later on. Sometimes people have very limited data plans. I know people in Europe who have 30 MB data plans for a month, and if you exceed that, then you'll get charged very, very highly. So there's multiple reasons why, and genuine reasons why, you should support older or proxy browsers. And there shouldn't be any stigma attached as such. I mean, we all like to play with the greatest and the most cutting-edge stuff. But the realities of the world is we need to deal with everyone. And sometimes there's also what you call regulation or some laws regarding accessibility, and stuff like that as well, which need to be considered as well. So the second part is if we do know what your clients are. If you're looking at analytics and numbers, and they're indicating that you're OK on dropping support for IE 6, and 7, and potentially 8, is that fine? I think it depends on the context of the content. I think if you're making a government website, then there definitely is a stigma, because these services, like mandatory, they have to be viewable by anyone.  Is there legal legislation that requires the accessibility to old browsers? So the only legal legislation or legal things that exist for older browsers are accessibility. You can be sued for not having an accessible website. But that's up for the user to determine what accessible is. The stigma that we have, this industry seems to have this horrible stigma where you can't drop support for old browsers. You've got to go back to the question, what is supporting an old browser? Supporting an old browser for most of us means that we're going to test in it. So that's not support at all. That means you're testing in these browsers. Supporting is actually if anyone has a problem, you're going to fix it for them. That's support. So if someone has a problem using your website, yeah, you want to help that person out. But there shouldn't be any stigma attached with helping someone. But if you want to spend time making sure ahead of time that those people won't have problems, then that's how you spend your time. That's it. But the one problem I've seen is that, OK, let's say maybe by the statistics, each company services a stat and maybe they just decide to drop the IE support. And sometimes they're doing it in the wrong way. I mean, they try to sniff in the user agent or something and try to eliminate all the IE, which seem to be old, but many times they're doing it in the wrong way. So let's say I work for Nokia and I use your Lumia phone regularly. And my browser choice, well, it's not my choice, actually. It comes with an operating system. And it's IE10. And oftentimes I see the site like, oops, sorry. You have to update your browser. It's like, really? It's IE10. It's pretty decent. And I believe that service or sites should work. But I think they just try to sniff it out mistakenly and try to suggest me to upgrade the browser or just download some other browsers. But the thing is, like you were saying, we don't always have a choice. Users don't always have a choice. So that's something I have to just remind. People have to remind. So I guess on the topic of support, support is kind of a difficult, it is the verb that we always use in this discussion. And it implies that it is a binary decision.  And I think for many of our development cycles, our development approach support is kind of this sliding scale. And so Tom, with cutting the mustard, when a browser falls into unsupported, they get a core experience. So there is no unsupported. The idea is that everybody is supplied a core experience. Everybody gets the content. But the way it's displayed is very simple. So if there's additional content on the home page of the BBC News site, for example, like analysis and features, that's available. But you have to click it to go to it. So the experience is very basic. But you still get all the content. But then with the premium version, we'll just go and fetch all of that content and put it straight into the page for you. And is the difference, in your case, the amount of testing between core and the premium experience? I imagine you are not as actively testing the core experience. The core experience is so simple. It's a single column. We don't add any functionality into the page. So that's going to pretty much render on anything. I think Andy Clark, a well-known developer in the UK, a while ago released a Universal IE6 style sheet. The idea here was basically a style sheet that had very good-looking typography, but destroyed all the layout, killed all your floats, just kept it all in a single column. And the idea was give that to IE, give them nothing else. The content is there, and it's accessible, but you can forget about the visualness of the rest of the site. And I think that's a nice way for something to go unsupported is basically to fall into a pit of accessible content. So having an IE6 style sheet, which has virtually nothing, is kind of the approach we took for one of the large sections of GovUK. Because we used the approach that Tom was mentioning during the intro with using mobile first and then sending specific style sheets for IE6, 7, and 8. But IE6, they don't get any layout, because layout's added on desktop. So IE6 just gets a mobile view. So it has no, it's a single column. It's basically got typography, because that's all that it gets. I think it's a benefit as well, because people with IE6 or IE7 probably don't have a good computer. And so the fact that it's so simple means it will render like five or six times faster than other experiences. Right, it's so readable. And as long as users can get what they want. Experience is not killed. I think that's a good strategy, because there's so many sites which either support it or just send an error message saying that, OK, this site is not supported, and that's it. The user cannot do anything about that. So I think that's a very important thing, that you don't block anyone. You at least serve them the core experience. The first part of that question was if you know your audience. And it's really difficult to know your audience in a very, very accurate way. Even if you know using your statistics and your analysis, what are the browsers which are coming through? There are times in which you get a mention on the front page of Reddit, or you get slashed on it. Or an influential news website mentions you. And then you'll get this whole stream of traffic which is completely unpredictable. So even that premise of that question that you know your audience is flawed. So I think it's a good time to move on to the next question. This one to be asked by John Fellows. So this is an anonymous question. What's the best way to make legacy clients a visible part of the development process? So I think this is both visibility on the developer side to understand what is necessary to give them what you plan to give them. And also potentially on the executive side to better understand what, from a development cost perspective, is included here. At the BBC News, we made the responsive site, but it was a small team that did it. And then eventually we found it out to the rest of the department. And so we've had to go through a training process with everyone as they become engaged with the product. So we've got the designers thinking about the core experience as well. And they're thinking about progressive enhancement. So they start off with the core experience. And then they progressively enhance it and make the better version. The problem that we find is that many people just associate the core basic experience with a very thin layout. What they find harder to do is to probably try and understand that the core experience could be any width. And the premium experience could be any width as well. I also wonder, is there included on this, I think, there is a visibility of the perceived experience between legacy clients and modern clients? And one of these parts is performance, certainly. So just rendering a page or any sort of interactivity, the more modern browser, it's going to be quite a bit more responsive. Is there a good way to demonstrate the difference between the user experience of someone on an older client versus a newer client? And is that something that the executive team wants to see and understand? Maybe I would say, let's say some UI, or I would say UX, using some Ajax-y type of interaction. And that works probably wonderfully on the latest graced browsers. Chrome desktop works nicely. But yeah, they show the same UI. And let's say all the mobile browsers or it could be Android, all the Android and stuff, it's probably going to look really janky, or maybe even unveil, you know. A lot of us manage the expectation, though. People on the old browser, people on IE6, who are stuck on IE6 in their corporate environments, they'll be used to an internet which is not quite like the internet the rest of us use. So while, for me or for you, browsing a website in IE6 will feel painfully janky and painfully horrible, they're kind of almost expecting that. And people aren't left on these browsers because they want to be there. They're there because those are the browsers they have because corporate IT have said that's what they've got. So it's all a case of managing expectation for those guys. Those people, if they know they're getting a janky experience, they come into that knowing.  And they joke with me like, is this supposed to look that bad? And it was like, I think the developer picked that color for you. It's like, no. They know the internet's horrible. Yeah, I mean, the thing is just to add or maybe even remove from my point, they might be used to it when they're working but for sure they're using the internet at their home or on their mobile and transit or something. So they know what the real internet is like and it'll be even more frustrating for them to see the internet as it is in the wild on IE6 all the time at work. Go and sit next to them at work. They're like sort of paying at work anyway. They know. Calvin's feeling something there? Yeah, actually I was gonna ask you what you just said but I wanted to ask specifically, is there a way to, if people have these different experiences at work and at home, they know your site's different when they're actually at work and something might be missing functionarily that they're used to at home. Is there some strategy we can take to make them not frustrated at us seemingly like they're suddenly hitting a broken version of the site that they were used to? I think this comes back to the approach with cutting the mustard. You make sure they can get the content they need to get still. While it'll look different, it'll feel a bit different as long as they can achieve the goals that they need to achieve. It's the best you can do for them. True, I guess. I think what I'm hearing from both of you is that there is kind of, both strategies include a degraded experience for older browsers in some way and that seems to scale pretty well but that does mean that we do have at least two experiences. And so if we are in a situation where you have someone that has seen both of those experiences, is that going to be a problem? I think that's fine because we can't, like I said in the talk, we can't make a premium experience that works across the whole spectrum of browsers because polyfilling and mobile internet connections are so hard to marry up together. So it's gonna, it has to be good enough because there's no other way. No. Yeah, it's better than just showing them that oh, your browser is not supported by. You know, it's at least better than that. I guess, sorry, the one caveat to what I just said is that if you do server side detection and sniff the old browsers, which is probably something, because normally people, when they talk about UA sniffing, you think about, oh, is this a mobile device or is this a desktop device? Whereas I think now we should probably be thinking about is this an old browser or a new browser? I think that'd be an interesting. In your case, would it be, is this a, does this browser cut the mustard? Yeah, you could do that on the server, if you wanted to. Right, like, you know, the old browser, that doesn't support JavaScript. It doesn't understand, you know, JavaScript feature detection, then you have to rely on the server side. All right, I'd like to move on to the next question. This one comes from Dustin Caston. Dustin's up here in the purple. Hey, so what as a community can we do to help the holdouts of legacy clients such as the government and IT departments too? Nothing. That was my answer as well, I was gonna say nothing. So I did a little bit of research on kind of around this point before I came. The same pool said to me earlier, I've built a thing, so which takes your Google Analytics and splits out browsers with graphs. You can see browser usage over time. So it's called browser matrix, takes in your Google Analytics account and then just charts the trend lines for browser. Paul said it'd be really cool if it could show future trend lines. So I went and had a look because I'm a nerd. IE6 is in seven's trend lines on GovUK. They're going down. IE6 lost half a percent in the last six months. What percent was it? It's gone from just over one to around half. Is that any particular time of the week? So it can also show you stats on a day-by-day, seven-day rolling basis. And during the week, six is above that. And at weekends, it's not really there. But I guess the question is like, but in the case like IE8 would be a better case. So like those guys, they're going down, they're gonna get there. And from the government perspective, like working in government, everyone is painfully aware in government that we're tied into these horrible contracts that require us to have IE6 and everyone's working to try and get out of them. Like no one is trying to stay in that world. There's not much a development community can do to help that. And on GovUK, we have a browser bar that pops up if you want an old browser that says try and upgrade, which hilariously, we won a design award earlier this year and a whole collection of screenshots that in news articles, you could see that browser bar. So, made us smile that these people writing reports for fairly large magazines online still use old browsers as well. But in terms of government and massive corporates, very aware we're trying to get rid of it internally. A question from the audience, Daniel. So, we always want to allow our users to be happy and I looked at some numbers and we have IE, all of IE is like 8% of our traffic, maybe 4% of our traffic. But is it worth spending the effort versus things like developer happiness and redemption? Sounds like it's not worth the effort for you. Sounds like you're doing well. I'd say it depends. I mean, those old devices might bring a lot of traffic to your site, but do they bring a lot of revenue? And... Right, I think that's something that it's, I don't know that we've seen a lot in the way of business metrics that are segregated by browser or by connectivity or by the performance, the load time of the site. But I think it's worth looking into kind of how those technical metrics of the site and of those users translate into their success on the site. I guess to get back to Dustin's question, we're talking about what our community can do to help legacy clients. So Google Apps dropped support for IE8 last November. And Google Analytics dashboard has dropped its support for IE8 in a few months. Google has a policy of only supporting the most recent and the last version. And so Google's being kind of aggressive in this and saying you just have to upgrade in order to use it. You can't use Google Docs on IE8. But is there anyone else that is in a position where they can help move this forward, or were you just in a case where we are just waiting for those trend lines to naturally go down over the course of years as we did with IE6? Internally in UK government, I'd love to say more, but there is work going on to fix it there. But yeah, it's still, there are people trying. One more thing that I wanted to add was a lot of these things are decided at the contract level. Sometimes what happens is, I can at least talk about the Indian government, sometimes what happens is they don't make the government websites. They sometimes send it out to a contractor who makes it for them. And usually things are decided at, when the contract is signed. And if there's a clause saying that, okay, IE6 will be supported, it has to be supported. So one of the things is to, as a web developer, if you're wanting for that contract to argue at that level before signing, that yes, I will not be supporting these things. I might be supporting the newer versions. And the second thing I wanted to mention was this problem is exacerbated by the fact that many people who were in government weren't really tech savvy that much for a while. They didn't really know about browsers and stuff like that. But with newer devices coming in, people are having iPhones and iPads and stuff like that, they still might not know what a browser is or not care. But they know that, okay, whatever this website that I'm sending the contract for, it has to work on my iPad, for example. So they're more focused on those things, on devices rather than the older browsers. So that mind shift is happening a little bit. But once again, as web developers, before signing the contract, you have to see it and be very careful about that. Talking about contracts, all contracts that the UK government signs now cannot have anything which even hints at vendor lock-in or device or browser lock-in. Anything that hints at a specific version has to be removed before contracts can go out to pretend there's nothing that's allowed anymore. A comment from the audience, Mary from O'Reilly. Hey, so just going back to, we were talking earlier about how frustrating it is for your co-workers if they have one browser version at home and one browser version at work and those types of scenarios. I think we might be referring to a very specific portion of the world in that those are the people who are very tech savvy who have the latest and greatest things who, yeah, you know, bigger and newer is better. But what about the rest of the world that, you know, updating your browser is scary because it means all of a sudden you don't know how to use it anymore. So there's people who consciously make the choice to not update because of that. So, I'm sorry? Your mom's. Well, okay, so yeah, that's an example. My mom does that. But I mean, it's a legit scenario. And by eliminating the ability for them to view your website, you're basically telling them they don't matter. Yes, I think change a version is real for everyone in a lot of cases, browsers and website features as well. I mean, my take here is that a lot of it is up to browser makers themselves to make transitions as smooth as possible. We're good now because the problem was always IE, right? Or more like corporate IE. So people would build corporate intranets and they would rely on ActFX. And that's why we're in a situation where there's so many corporate desktops that can't upgrade. I was going to mention that too. Many times you can't just download, install any browsers and any computers. You have to ask IT guys to do that, you know? So obviously, you know, probably that's where legacy IE is coming from. So, you know, if you're, you know, working for the web services for, like, enterprise and such, this is something like a really huge issue. And you have to really watch out at your browser stats and what you're, you know, the people using. So I want to move on to the next question, but before I do, I want to get Jeffrey Bertoff from Microsoft, since we are talking about IE a lot. It'd be nice to get his comment here. Yeah, thank you. So, first to defend Microsoft here, one thing I want to make sure, and I do that proudly, because one of the things I want to make sure that we understand is that Windows XP that runs IE8 was a great product, and that's why people still use it. So anytime we build great products, we're going to have to deal with legacy browsers, because they're going to stick around. So if you look at a parallel to iOS, so we just stopped, or Apple just stopped supporting, was it 3GS? With updates, which means that iOS 6 is the last version they'll ever see. But those phones are going to continue to be around, and they will become a legacy platform that we have to support. So when we have good products that are going to stick around, it's something that we need to plan for. So these type of discussions will always be relevant. Well, I think in this, in this case, we're in our situations that Windows XP is a great product, but the problem there is that users of IE on Windows XP don't have an ability to upgrade their browser to the next version of IE. Yeah, so that's, you know, that's something that's clear. If you are on that platform, there's two different things that are going to cause you to stay on older versions of IE. One is it's your environment, you don't want to upgrade or you can't upgrade. Or the fact that with IE, you can't upgrade past IE 8 if you're on Windows XP. So our, our, at Microsoft we use JavaScript, we use our JavaScript engine, HTML5 and a lot of our products. And so whether it's writing apps for Office or in embedded or in Xbox or in Windows 8 apps, all of that can be done with the JavaScript engine. There's definitely a coupling there that makes us have to draw some lines in the sands as to where we can, can update and where we can't. So it's not that it's, there's reasons behind it, I guess is what it would say. Sure, and I guess we can close this discussion for now with the end of support date for Windows XP is April 2014. Right. So that trend line that we're watching for IE 8 will may potentially drop down more substantially at that point. So there's like, there's a whole other like dark world which no one talks about. Talking about like old IEs and the fact there are other things which we have to support which no one talks about. And they're old screen readers. Actually, screen reading technology. Before we move on to screen readers, I want to get Alex Russell's comments here. Hi, thanks. Alex Russell, one of my first projects at Google and I'm going to talk a little bit about this frame which was necessitated because you didn't do what you just said. Microsoft didn't take care of the legacy. Right. It was Microsoft's responsibility to do that and instead Microsoft chose not to invest in making sure that users of Windows XP could continue to use modern technology. So having done the cleanup work for you, I just need to make the point that you didn't. This is going to get exciting. For the moment, we're going to move on to the next question. This one, Matias Kuzman, Kautzman. Hi. My question is, for how long is it worth polyfilling features for legacy browsers and taking the hit in performance or dev productivity? What factors should influence the ultimate choice to see support for a legacy client? So in a lot of cases, our method of dealing with older clients that don't support a certain capability is polyfilling them. We started out with the JSON2.js, JSON polyfill, and we've managed to polyfill many, many things. These polyfills do have performance costs, not only in the bytes that we have to send on the wire in CSS and JavaScript, but also in runtime performance. So performance of polyfills is a concern. And what are the other aspects that could help influence the choice to see support might not be the right words, but change the support level? So maybe a good example is with animations. So a couple of years ago, people would do JavaScript animations, and now we try to see all animations with CSS, and we just say, well, if you don't have that CSS feature, you just get a janky animation. I'd say that's fine. I don't have a problem with people in IE getting janky transitions. Especially with jankiness. If you want to have some animation, but it doesn't work in some browsers, I think you have to just kill the animation. I think not moving at all, it's far better than janky animation. So I want to say janky, I'll actually mean binary. It's closed, then it's open. But then with a more modern browser, you can slide it in and go. Although I guess an issue with that is not so much with Polyfill. Something I've seen recently where I made a panel appear, and I gave it a nice animation grow. It worked lovely in iOS, but when I checked it on an Amazon Kindle Fire, it had a great browser, it supported the feature, but it was really janky. Because the hardware just couldn't keep up. Right. And not just the hardware, actually the Amazon Kindle, the silk browser is a proxy browser. Or maybe a marketing term is like cloud-accelerated browser, or whatever that is. So that has to keep in mind. It's not like all JavaScript is forced to work in some WebKit, it works in as way you want an proxy. But I think, I guess, when we talk about legacy clients, there's a few reasons why, like we use the term legacy, and that does happen to usually refer to them being old. But I think the reason that we don't embrace them and love them is because they may have bugs, they're probably slower than what we're used to, and they lack features that we want to use, that we're interested in using. So it's not necessarily that they're old, but they aren't good as what we want. And I mean, is it worth forming a policy around how to change your support level for browsers? What's your take on this? I think, ultimately, there's going to be so many variations that you should stop with the mindset of supporting or not supporting those kind of browsers or not. You should just go with the thing of progressive enhancement and feature detection. And because what will happen is you say that, okay, I'm going to support this old browser, but ultimately, what will happen is you'll get more and more devices. Nowadays, we get devices which are running a very good version of Android, but are less than $100. So even though they're running like a very, very nice version of WebKit, for example, the performance is such that it really makes them almost like a legacy browser in many cases. So how do you define a legacy browser is going to become more and more muddled because a browser with a very, very nice phone can behave like a legacy browser if the network connection sucks. And there's a lot of smartphones coming up with good versions of WebKit, but very underpowered. Yeah, so it's a strange time. So you've got like a Nokia C5 that's an entry-level phone. It's got a really bad process and RAM, but it will have a really good version of WebKit on it, so it will render the page really well. And then you can compare that to an iPhone 5 that has Opera Mini in it, so the capabilities would be less or you would at least get a static version of the site. It's a very bizarre issue to try and solve. I don't think there is a magic bullet. Actually, in the modernizer web page and the documentation say, it's because you can use Polyfill doesn't mean you should. I think I said that in the site. It's true. Yeah, so it's really... So that's really, developers have to decide what you want to really support.  And some browsers have been like round corners, really. You don't always need this. You don't always drop certain, especially if it's just UI print as you can drop that. But I guess the other part of this is that there are some features. There's a set of features that you cannot let degrade gracefully. WebGL, GetUserMedia, Web Audio API, these many can't be polyfilled. And so what is the responsible way in defining a browser support policy when you're dealing with features of this sort, where you're providing an experience that competes with something on a native platform and it's not content-based? So you mentioned WebGL. I can give you an example there. On the BBC News, we started doing WebGL content now. We've got the Mars, we have the Mars lander 3D object. So if you had WebGL supported, you could spin it around and zoom in and stuff like that. And it was really nice. But then there's no polyfill in that. So what other browsers would get is an image gallery of the 3D model. So we wouldn't try to polyfill the content. We'd offer an alternative content. Okay. I'd like to move on to the next question. John Rezeg, if you could, would love. Thank you. So I took this question because I didn't like it, so I didn't want it to be asked. The question was roughly that they felt that you could get away with supporting browsers that did not have JavaScript. And I feel that that is not the case, that for most content websites, you need to support clients that do not have JavaScript. But to spin it into a more legitimate question, what about web applications, where you're not dealing with strictly content-based? I feel like most of you are dealing with content, where it's like, here's a news article, here's some information you want to read. Obviously, in that case, there shouldn't be a barrier in between you and reading that. But what about a whole application that is built in very JavaScript-centric? Should you be making a fallback for that? I know if you want to use Gmail and there's no JavaScript, you fall back to this form-based thing. And I have no idea how well that's maintained, but that's got to be someone's sad job. But I mean, I assume not everyone wants to be doing old HTML tables and doing the forms. So is that legitimate thing? Should people be worrying about that for their applications? Tom? I'd say it's always best to create an experience that doesn't just immediately fail when something goes wrong with the JavaScript. So I think Gmail is a great example that you point out. So it's something that is a service. It is purely functionality. But then I think we should just make the experience. There's a great... In fact, I'll let you say this. So I read on the GDS website about why you should make progressive enhancement with JavaScript. Do you get what I'm talking about? No? Okay, so Ed said that instead of build your applications like an escalator instead of a lift, do you get me now? Was that you that said that? I don't think I wrote that. Was it Jake? I remember me. I read it on the GDS site. So somebody said, if an escalator breaks, the worst thing that's going to happen is it's going to turn into some stairs so you can keep walking up. So you can keep walking up it.  There's nothing you can do. And it's the same with JavaScript applications. Well, I guess there's plenty of JavaScript applications. Diagramming tool and IAM client, like many of these rely on real-time data, cannot be done with page refreshes. And so some of these do require JavaScript for their interactions. Jake wrote a really good blog post on this recently. Yeah. Jake, would you like to comment on how... For those who couldn't see, Jake was waving quite madly. I'm kind of perching on the stairs because I was actually on the way to the bathroom, so he caught me just at the right point. Any website that has a loading bar is a missed opportunity. It's a missed opportunity to serve the content directly without JavaScript and then get JavaScript in there to do it. And Gmail is an example of that. I mean, Gmail should have URLs. I should be able to bookmark a page to a particular email. And when I hit that, I should get that content on the page and then JavaScript can come in and add the rest. I mean, it is just a series of tabs and forms. It doesn't need to depend on JavaScript at first render. But the Gmail web app also has URLs that are permalinkable for all messages as well. One thing I wanted to mention just to repeat, which matches this use case is you have JavaScript applications heavily reliant on JavaScript, but you also have these phones which are coming up which will have browsers which support JavaScript, but these are underpowered phones in which it will be actually better for them to get a version without JavaScript than to get a version with JavaScript which runs really, really slowly. So in those cases, it might be better for them to get a lighter version of the page. And the other thing is search engines. Once again, if you have single-page applications, you can run Node and Phantom.js and use a solution with that. But I still think that it would be better to just have something which can be run without JavaScript. I suppose in that search engine optimization, it's a balance of what's easy for you, and if it's important for you to have that content available to search, you need to find a way to do that either through progressive enhancement or through a complex server-side rendering farm. The alternative, the other side of the argument is that making an application that's purely reliant on JavaScript is probably a lot faster. So I would say you mean if times... If you're trying to get something up and running fast, if you're prototyping, if you've got deadline issues, then that is an option. You can do that. However, I would always try to make something a progressive enhancement. So in the slide where I spoke about the things that were nice, so accessibility, SEO, working without JavaScript, usability, all of those things are idealisms. But on their own, they're probably not great arguments that you can go to your manager and say, hey, this doesn't work with screen readers, because your boss will probably turn around and say, I don't care about screen readers. But when you add them all together, they create something bigger, and that's the whole point of the web. And all of those things, if you develop with all of those things in mind, then you're kind of developing and in the current of the web, you're swimming with the web as opposed to swimming against it, which is what I think is applications that are purely JavaScripts are swimming against a little bit. So you can make things that are purely JavaScript, but I think it's better and you get added benefits by building things in a progressive enhancement. Matt and May, I see you have a comment. We're going to have to make this very quick, but I want to get your voice here. Sorry, somebody says accessibility and I go crazy. I just wanted to add on to this, and I think BBC is a great example of this, that the users of assistive technology are not legacy or down-level users either. If you have something like data visualization or chat or anything interactive, those are still things that you need to make accessible, whether or not you're going to serve them to legacy clients. Everybody is expecting that. They have the latest assistive technologies, like everybody else, and it's important to decouple them from, well, we'll just serve them the text-only site because that's the same thin grill they've had since the 90s. Yeah, 98.4% of screen reader users have JavaScript enabled from the recent WebAIM survey. But guys, I think we're out of time. Thank you very much to our panelists for joining us up here, and thank you, guys.