Podcasts about css cascading style sheets

Today we discuss CSS, and the preprocessors + variations such as SCSS, SASS, CSS Modules, and Styled Components.CSS (Cascading Style Sheets) is a declarative language that controls how webpages look in the browser. The browser applies CSS style declarations to selected elements to display them properly. A style declaration contains the properties and their values, which determine how a webpage looks.A CSS preprocessor is a program that lets you generate CSS from the preprocessor's own unique syntax. There are many CSS preprocessors to choose from, however most CSS preprocessors will add some features that don't exist in pure CSS, such as mixin, nesting selector, inheritance selector, and so on. These features make the CSS structure more readable and easier to maintain. SASS, SCSS, and LESS are examples of theseA CSS Module is a CSS file in which all class names and animation names are scoped locally by default. The key words here are scoped locally. With CSS Modules, your CSS class names become similar to local variables in JavaScript. By the way, a 'CSS Module' is just a .css file. You call it a 'CSS Module' if you plan on using it with a CSS Modules compiler.Styled Components are tagged template literals combined with the power of CSS, which allows you to write actual CSS code to style your components. It also removes the mapping between components and styles – using components as a low-level styling construct could not be easier!ResourcesCSS PreprocessorsSASS vs SCSS vs LESSCSS ModulesStyled ComponentsConnect With Us!Instagram: @badforeducationpodcastTwitter: @badforedupodEmail: badforeducationpodcast@gmail.comSend us questions! Or say hello to  us via email!Want a free $20 Amazon gift card and to start your own podcast with Buzzsprout?It's as simple as one click in our link below. Get started today, and have access to their extensive network and assistance. Podcasting isn't hard when you have the right partners!Click our link here

Sam Taylor is the author of "The Coding Workbook: Build a Website with HTML and CSS", a book created to teach anyone how to build a website - without a computer. She has a Master's degree in Curriculum Design and works as a technical curriculum developer. She is passionate about providing educational opportunities for everyone.Episode NotesMusic used in the podcast: Higher Up, Silverman Sound Studio"The Coding Workbook: Build a Website with HTML and CSS". https://nostarch.com/CodingWorkbookHTML - Hypertext Markup Language is the standard markup language for documents designed to be displayed in a web browser. It can be assisted by technologies such as Cascading Style Sheets and scripting languages such as JavaScript. (wikipedia)CSS - Cascading Style Sheets is a style sheet language used for describing the presentation of a document written in a markup language such as HTML. CSS is a cornerstone technology of the World Wide Web, alongside HTML and JavaScript. (wikipedia)"Hello World: A Complete Python-Based Computer Programming Tutorial with Fun Illustrations, Examples, and Hands-On Exercises" by Warren Sande and Carter Sande.Python - an interpreted, high-level and general-purpose programming language. Python's design philosophy emphasizes code readability with its notable use of significant whitespace.Teach for America - a nonprofit organization whose stated mission is to "enlist, develop, and mobilize as many as possible of our nation's most promising future leaders to grow and strengthen the movement for educational equity and excellence." (wikipedia)#100 Days of Coding - A challenge to code for a minimum of 100 consecutive days and tweet your progress. There is a website about this challenge. https://www.100daysofcode.com

Hello 通勤家族，歡迎收聽Look Back Sunday回顧星期天，John老師在這個節目會彙整過去一年不同國家與主題的熱門跟讀文章，讓你可以在十五分鐘內吸收2020年最精華的世界時事趣聞！我們先從台灣的趣聞開始，Let's get right to it!   Topic: Original icon font promotes beauty of Taiwan   日本設計師Holoko和英國工程師Rob攜手創作出100個代表台灣的文字圖標（Taiwan Icon Font)，提供免費下載，期望透過台味十足的圖標，讓世界知道台灣的魅力，吸引更多人來台觀光旅遊。 Holoko and Rob, a Japanese designer and a British programmer, recently joined hands to design a hundred Taiwan-themed icon fonts in hopes of introducing local tourism attractions and attracting more tourists to Taiwan. 文字圖標是什麼呢？使用者只要打入對應代碼，便能產生小圖示，也可以像文字一樣改變圖示大小、顏色。 But, what's an icon font? Icon fonts are fonts that contain symbols and glyphs instead of letters and numbers. Internet users can style them with CSS (Cascading Style Sheets) to create original designs in a variety of colors and shapes. 圖標種類分為四大類，分別是觀光景點、產品、交通、其他。除了全台從南到北和離島的觀光景點之外，還有珍珠奶茶、台灣鐵路、YouBike等等代表台灣的事物都變成超可愛迷你圖示。 The aforesaid icon font is organized into four types, including sights, products, traffic and more. In addition to famous Taiwan attractions and offshore islands, various cultural features such as pearl milk tea, Taiwan Railways Administration, and YouBike have been converted into cute mini icons. Taiwan Icon Font官網寫道，創作者的發想理念緣起於2019年8月陸客來台禁令生效，對台灣觀光業造成衝擊，然而，設計師認為來台灣的不只有中國人，台灣的美足以吸引來自世界各地的人，盼能藉由小圖示宣傳台灣之美。 In 2019, China imposed a travel ban that froze individual tourists' permits to Taiwan, which caused a significant impact on Taiwan's tourism. Against this backdrop, Holoko and Rob launched this project with the hopes of bringing more people from around the world to discover the beauty of Taiwan, according to the designers' official website. 文內自介寫道，「我們支持台灣，因為台灣有好大的吸引力，而且台灣就是我們的好朋友！」熱愛台灣的設計師不僅被台灣景致吸引，對他們來說，台灣更像是好朋友。舉例來說，珍珠奶茶在日本掀起的熱潮、每年增加的旅台日人、台灣2011年傾囊相助日本東北地震賑災，可見台灣與日本友好關係。 In addition, they stressed how “we support Taiwan not only because Taiwan is attractive but also is our friends.” Among other highlights, they remarked that Taiwan-Japan ties have been blooming ties in recent years which can be seen in the pearl milk tea craze in Japan, an increase of Japanese tourists to Taiwan and donations to the Japan earthquake in 2011. 「WE STAND BY TAIWAN」是計畫口號，呼應整體概念。設計師支持台灣自由、尊嚴而開始了這個計畫。目前已經出了第一版，而設計師們也會持續更新改善，讓世界認識台灣。 “We Stand By Taiwan” the slogan of the project, reflects such design concepts. The two foreign creators launched this project with the aim of supporting freedom in Taiwan. So far, the first version has already been released and they will continue to improve their original font to let more people know about Taiwan. Source article: https://chinapost.nownews.com/20200114-931025   Next Article   Topic: Legendary singer/actress Barbra Streisand lauds Taiwan's virus control   In a tweet on April 5, legendary singer and actress Barbra Streisand praised Taiwan for its handling of the COVID-19 outbreak. “Taiwan, despite being just 100 miles from mainland China with regular flights to and from Wuhan, has successfully staved off the worst of the coronavirus pandemic,” the superstar tweeted. 在四月五日的推特中，傳奇歌手、演員芭芭拉史翠珊大讚台灣對於武漢肺炎的爆發處理得宜。這位超級巨星推文說：「儘管台灣距離中國大陸僅約一百英里，與武漢間還有例行往返的班機，但已成功擊退新冠病毒流行病最嚴峻的挑戰。」 She pointed out that Taiwan had only five deaths at the time, and that most schools and businesses remained open. Later that day, President Tsai Ing-wen retweeted Streisand's post, saying that it is encouraging to have one of the world's most distinctive voices speak up in support of Taiwan's proactive approach against the outbreak. 她指出台灣至當天為止只有五例病死，大多數學校與商家仍正常運作。蔡英文總統隨後在當天亦轉推這則推文並說，世界上最特別的聲音，能發聲力挺台灣主動對抗疫情的方法，這真是令人大受鼓舞。 “We are more than willing to share our experiences with friends around the world as well,” the president wrote, followed by hashtag #TaiwanCanHelp — a slogan signifying Taiwan's willingness to contribute to the world during the pandemic. Fans have suggested that Streisand stage a concert in Taiwan after the crisis, so she can see this beautiful land in person. 蔡總統並說：「台灣很樂意與世界各地的朋友分享我們的經驗。」在文末並附上「台灣能夠幫忙」（#TaiwanCanHelp）的標籤——藉此口號表示台灣願為全球防疫盡一己之力。還有歌迷建議史翠珊在疫情平息後來台開唱，親自看看這片美麗的土地。 Source article: https://www.taipeitimes.com/News/lang/archives/2020/04/17/2003734741     Next Article   Topic: Taiwan's culinary innovations cause a stir in the world of pizza   Forget your pepperoni or other pizza toppings: Pizza Hut Taiwan has teamed up with Menya Musashi, a popular Japanese ramen restaurant chain, to serve up the world's first ramen pizza, and it has attracted global interest after a CNN report about the new mashup was published on the front-page of its Japanese version. 忘掉你愛的臘腸或其它配料吧。台灣必勝客近日與熱門日本拉麵連鎖店麵屋武藏合作，共同推出全球首創的「拉麵披薩」！美國有線電視新聞網（CNN）對此混搭的相關報導，還衝上該媒體日本版網站首頁，並進而引發全球關注。 The new pizza has the toppings of a Japanese-style barbecue pork ramen — complete with thick noodles, barbecue pork slices, fresh chilies and white sesame, as well as a half-boiled egg sitting in the middle. It is also garnished with green onions and bamboo shoots on the side. 基本上，這款新口味披薩上有著日式叉燒拉麵的配料——包括粗麵條、叉燒肉片、一些辣椒末和白芝麻，中間還擺著一顆半熟的糖心蛋，旁邊則裝飾著一些青蔥及筍片。 Pizza Hut Taiwan told CNN that its creative pizzas are just a way to introduce some fun into the customer experience. “Taiwanese consumers live a high-pressure life with long working hours and a high cost of living. The food scene has become an exciting and creative escape,” said Lily Chou, the company's marketing director, adding that it is definitely the first ramen to be served as a slice. 台灣必勝客告訴CNN，它的各種創意披薩其實是想為顧客們帶來一些樂趣。行銷總監周佳麗指出︰「台灣消費者過著高工時、高生活成本的高壓生活，而令人興奮的創意美食已成為逃離壓力的出口，」她還說這絕對是第一款用手吃的拉麵。 The Taiwanese are known for their creativity in making special food and drinks: some of their previous mashups have included matcha green tea pizza, durian pizza, stinky tofu pizza, and even bubble tea pizza. Also known as “boba tea” or “pearl milk tea,” the famous tea of Taiwanese origin mixed with milk and small tapioca balls has become a global sensation in recent years. Domino's Taiwan even caused a pizza war by launching its “bubble tea pizza” late last year. 台灣人向來以製作新奇飲食的創造力而聞名，之前推出的混搭還包括抹茶披薩、榴槤披薩、臭豆腐披薩，甚至珍珠奶茶披薩等。珍奶在英文中又被稱作波霸奶茶或泡沫奶茶，這種知名茶飲一般混合著牛奶，及樹薯粉製成的粉圓，近年逐漸在世界各地造成轟動。台灣達美樂去年底就因為推出黑糖珍珠披薩，而掀起一場披薩大戰。 “It might be the ultimate meeting of eastern and western cuisine — Taiwan's famous bubble tea as a topping on a Domino's pizza,” CNN reported. Domino's Taiwan originally planned to offer the dessert pizza covered in brown sugar pearls, cheese and honey for a month, but the popularity of the bubble tea pizza secured its spot on the regular menu, and rivals have been trying to join this trend. “In Taiwan everyone loves the texture ‘Q,' which means chewy or bouncy in the way boba is, and this pizza was indeed very ‘Q,'” Lev Nachman, a US PhD candidate conducting research in Taiwan, told CNN. CNN稍早報導說︰「台灣著名的珍奶化身達美樂披薩配料——這或許是東方和西方飲食的終極交會。」最初台灣達美樂僅計劃推出這款覆蓋著黑糖珍珠、起司、蜂蜜的甜點披薩一個月，不過因產品大受歡迎，最後被加入正式菜單，其它對手亦開始追逐這股風潮。 在台灣做研究的美籍博士候選人南樂對CNN說：「在台灣，每個人都愛『Q』、也就是有嚼勁、會彈牙的口感，就像珍珠粉圓，而這款珍奶披薩口感的確很『Q』。」 Source article: https://www.taipeitimes.com/News/lang/archives/2020/07/06/2003739406   Next Article:   Topic: Taiwan to stop, not block, local sales for Chinese TV streaming services   Taiwan plans to stop local sales for Chinese Internet television streaming services operated by the likes of iQiyi and Tencent Holdings, according to regulations released this week, but does not plan on blocking the services. 根據本週發布的規範，台灣將禁止中國的網路電視串流服務在境內進行銷售活動，受到限制的對象包括愛奇藝與騰訊控股等業者，但是串流服務並不會遭到封鎖。 Democratic Taiwan, claimed by China as its sovereign territory, has long been suspicious of Chinese attempts to sway its population, including by use of fake news spread online and efforts to influence Taiwanese media. 被中國聲稱為其主權領土的民主台灣，長久以來相當懷疑中國潛移默化台灣人民的企圖，包括利用網路上散布的假新聞，以及各種影響台灣媒體的手法。 The Ministry of Economic Affairs said late Tuesday that the rules barring Taiwanese companies from selling or operating as sales agents for Chinese Internet streaming services will take effect Sept. 3. The service iQiyi applied in 2016 to set up a Taiwanese subsidiary, but was rejected because Chinese companies cannot operate online streaming services there, the ministry said. 經濟部於週二晚間宣布，台灣公司禁止經銷或代理中國網路串流服務的規定，將於九月三日正式上路。經濟部表示，愛奇藝曾於二○一六年申請成立台灣子公司，但是遭到拒絕，因為中國公司不得在台灣從事網路串流服務等業務活動。 However, Taiwan is not blocking or banning them, the National Communications Commission said. “People can still watch and pay for overseas subscriptions,” commission deputy chief Wong Po-Tsung told Reuters, adding that officials would ensure that subscribers' rights are not affected. 不過，國家通訊傳播委員會表示，台灣並不會封鎖或是禁止這些平台。通傳會副主委翁柏宗向路透表示：「觀眾仍然可以收看，並且付費海外訂閱。」他補充說，政府官員會確保訂閱者的權益不受影響。 The commission ruled in May, after months of debate, that Chinese online television service providers would not advertise their services in Taiwan. 經過數個月的爭論後，通傳會在五月做出決定，中國的網路電視服務提供業者不得在台灣廣告和促銷其服務。 Baidu-backed, Netflix-like iQiyi said in a statement issued by unit iQiyi International that it was paying close attention to the situation and that it believed it should “not become the specific target of legislation.” “We wish to see the Taiwanese government departments involved recognize the benefits of an open market economy,” it added. Tencent, which runs Tencent Video, declined to comment. 由百度持有股份、類似Netflix的串流平台愛奇藝，在一份由愛奇藝國際發布的聲明中表示，該公司正在密切注意情況，並且認為公司「不應該成為立法的特定對象。」該公告補充表示：「我們希望看到台灣政府的相關部門認知到開放市場經濟的益處。」經營「騰訊視頻」（在台灣以「WeTV」上架）的騰訊則是拒絕發表評論。 Taiwan has a free Internet, unlike China, which blocks sites such as Google, Facebook and Twitter. Taiwan also does not ban access to popular Chinese apps like WeChat or sites like Baidu. China does not permit Taiwanese firms to offer Internet television streaming services. 台灣擁有自由的網路，不像中國封鎖包括Google、Facebook、Twitter等網站。台灣也沒有禁止使用WeChat等受歡迎的中國手機應用程式，或是封鎖百度等網站。中國則是不允許台灣公司在當地提供網路電視串流服務。 Chinese Internet giants have come under pressure internationally, led by the US, where President Donald Trump ordered ByteDance last week to divest video-sharing app TikTok's US operations within 90 days, the latest effort to ramp up pressure on the Chinese company over concerns about data security. 近來，中國的網路巨頭在國際間受到不少壓力，首先是美國總統川普簽署行政命令，要求「字節跳動」必須在九十天內出售或分拆旗下影音分享手機應用程式「抖音」的美國業務。這是川普政府因為資訊安全顧慮，而對該中國公司增加壓力採取的最新動作。 The US Securities and Exchange Commission is investigating iQiyi after a short seller accused it of inflating user numbers and prices, it said last week. 上星期，愛奇藝則表示美國證券交易委員會正在調查該公司，原因是受到一間美國放空機構指控造假，誇大訂閱戶數量和營收。 Source article: https://www.taipeitimes.com/News/lang/archives/2020/08/23/2003742111 每日英語跟讀Podcast，就在http://www.15mins.today/daily-shadowing 每週Vocab精選詞彙Podcast，就在https://www.15mins.today/vocab 每週In-TENSE文法練習Podcast，就在https://www.15mins.today/in-tense     用email訂閱就可以收到通勤學英語節目更新通知。

What is CSS (Cascading Style Sheets)? And how do you use in on a webpage? In this episode we talk about how to use CSS on an HTML page. CSS…

Laura Stevens:  Hello, and welcome to the Government Digital Service Podcast. My name is Laura Stevens and I’m a Creative Content Producer here at GDS. And today’s podcast is going to be on the GOV.UK Design System.    The GOV.UK Design System is a collection of tools and resources for designing and building products and services. It provides styles, components and patterns that are accessible. This helps hundreds of teams across the public sector design and build services that are of high quality and can be used by anyone.    The impact of the design system, created and managed by a team of 10 here at GDS, is significant. It’s used in central government, local government and has also been used by the NHS and international governments to develop their own design systems. It saves teams time and money and helps give people a consistent and accessible experience when interacting with government.    To tell us more is Tim Paul, who is on the team who launched the GOV.UK Design System. Tim has also been at GDS for a long time, he was on the team that launched GOV.UK in fact as well. We’re also going to be hearing from people from central and local government about how the GOV.UK Design System has helped their work.   So yeah, welcome Tim to the podcast.    Tim Paul:  Hi there, how are you doing?   Laura Stevens: Thanks for coming on today. And could you tell us what your job is here at GDS and how you work with the GOV.UK Design System?   Tim Paul:  Yeah so I guess my official job title is Head of Interaction Design. But for the last couple of years, I’ve mainly been kind of doing that as a Product Manager really for the Design System. So that’s a thing that we kind of kicked off a couple of years ago and we’ve managed to build a team around that, and develop a suite of products. We launched those back in summer of 2018 and yeah, I’ve been product managing that and working with the team closely ever since.   Laura Stevens:  So the Design System was launched back in July 2018. But what is the Design System made up of?   Tim Paul:  So it’s essentially a suite of 3 different products. So you’ve got the Design System itself, which is basically a website with guidance and coded examples for designers and frontend developers to use to design and prototype and build public services. So that’s the first thing.   And then there’s a thing we call the GOV.UK Prototype Kit, and that’s a piece of software that designers in particular can download and install, and they can use it to rapidly create very high fidelity prototypes that they can take into user research. And they can test out ideas before their, their team commits to building anything. So they can find out what the right thing to build is.   Laura Stevens: Yeah.   Tim Paul:  And then the third thing, which underpins both of those, is a thing we call GOV.UK Frontend. And that’s essentially a frontend framework, so it’s all the Javascript and the CSS [Cascading Style Sheets] wrapped up into a nice package that developers can install into their projects. And so the Prototype Kit and the Design System both use GOV.UK Frontend and that means that designers and developers are both drawing from the same kind of library of components and patterns.    Laura Stevens:  I heard you say before that you think of the Design System also as a service as well, what do you mean by that?   Tim Paul:  Yes. So as well as the 3 products that we provide, we also offer support and training. We’ve helped facilitate contributions to the design system and we’ve run community events and we have regular hangouts with our community of users and contributors. So we really think of the whole thing together as being an actual service, and we have you know, a multidisciplinary team to support both the products and that service.    Laura Stevens:  And when you were talking about the different parts of the GOV.UK Design System, for people who are listening and don’t know what a component is or a pattern or a style. Could you explain what those things are please?    Tim Paul:  Yeah, ok, I’ll have a go.   So when we first started out - figuring out how to make this thing, we did a lot of thinking about what were the things that were going to be inside the Design System. There’s no really established language for talking about this stuff. Although design systems as an idea are fairly well established now.    So in the end we settled on 3 definitions. And so we have what we call styles. And they’re the really low level building blocks that everything else is made out of. So it’s things like colour palettes and how your typography works and how your page layouts work and your grid system and so on. So those are the styles.    And then one level up from that if you like, we have things that we call components. And so components are chunks of user interface, UI. So they’re visible things that you can compose onto a webpage and that, and, and that makes your service. So it’s things like drop-down lists and tables and navigation and headers and footers. And all our components are built using code, the code that we provide in GOV.UK Frontend. And so that’s what a component is.   And finally one level up from that we have things that we call patterns, and patterns are a little bit more abstract. They’re centred around common needs that users of public services have. So for example, lots of public services require that people enter information about themselves like their name or their address and so on, and so we have design patterns which explain the best most usable way that we’ve found, to ask users for that kind of information.    And, we have even higher level design patterns so for example, it’s quite common that a public service has eligibility requirements that, that, that users must meet if they are able to use that service. And so we have a pattern for example, which explains how best to help users understand whether or not they can use your service, so that they don’t waste time trying to apply for a benefit or something that they don’t actually meet the requirements for.   Laura Stevens: And so now I feel like I, I know what it’s made up of, I know what those words mean. But why are design systems good for government? And in a previous presentation I found in the Google Drive in my research, you said the national motto of design system teams is ‘efficiency, consistency and usability’   Tim Paul: Oh yeah, I did say that didn’t I?   Laura Stevens: Would, is that why they’re good or have you changed your mind?    Tim Paul: I guess, no that’s almost been one of the most stable beliefs that we’ve held throughout the whole kind of time we’ve been developing these resources. There, there do seem to be 3 pretty stable fundamental user needs that things like design systems are good at meeting. And, and that’s that public services needs to be efficiently built, we don’t want our tax payers’ money to be wasted in people like reinventing the wheel up and down the country in different teams.   They need to be of a high quality. So they need to be really accessible and usable. And they need to be consistent with each other. So one of the big reasons that we made GOV.UK in the first place was to try and create a single unified consistent user experience for all government services because that helps people to be familiar with those services, which means that it makes them more usable. But it also kind of fosters trust because it’s much easier to recognise when you’re using a legitimate government service if they all look the same.    And the way that design systems help with those things is that you have this common suite of components and patterns that are ready made, pre-built, they’ve already been tested for things like usability and accessibility. And so that lifts up the quality because people are re-using existing things, it means that they’re not developing them themselves so that makes teams more efficient and productive. And again because they’re re-using the same suite of components and patterns, it means that different services made by different teams in different parts of the country in different departments, are all consistent with each other.   Laura Stevens: And I think that’s a point that I wanted to pick up on, is because I think as a user coming to GOV.UK, it looks like it’s just one big website.   Tim Paul: Yeah.   Laura Stevens: But it’s actually being managed, and being delivered simultaneously, by different teams up and down the UK.    Tim Paul: Yes. So like you say GOV.UK presents as this single, quite large website that’s full of different services and information and that’s entirely intentional, that was always the vision for GOV.UK. But we, anybody who’s worked on it knows that under the hood, it’s hundreds and hundreds of separate websites and they're owned and managed by different teams in different departments up and down the country. There is no single tech stack for the public sector or for government, there’s hundreds and hundreds of different ones and we don’t try to control what that stack should be.    And so the challenge that we’ve always faced is like how do we let all of those teams work pretty much independently of each other, but deliver something which is coherent and consistent and feels like a single user experience. And this is, this is what design systems are really good at because they, they provide this centralised resource that all teams can draw upon and contribute back to.    So not every organisation, or large organisation, requires a design system necessarily but I think government is maybe almost the best example of an organisation that can benefit from, from a tool and a service like this.   Laura Stevens: So yeah, we’ve got GOV.UK as this, appearing as one site but actually being operated by lots and lots of different teams up and down the country. So is that who’s using the Design System, all these different service teams?   Tim Paul: Yeah, so we think that most users of the Design System are probably designers or developers working in, on, in services teams in different departments up and down the country. And we’ve tried lots of different ways to measure usage, it’s important that we know who’s using our service and how and what problems they might be facing, so that we can improve the service for them.   So one thing we have looked at in the past is, is web traffic. That’s just visitors to the Design System website. And that’s quite useful for showing month on month growth. I think since we launched, we’ve grown the number of visitors to the site by about 250%.    Laura Stevens: So impressive figures.   Tim Paul: Yeah, yeah! It’s, we’re happy with that.   Laura Stevens: I wanted to ask about the community element of the Design System. So people are able to contribute their own patterns and how, so in terms of the number of patterns or number of components now, are most of them done in GDS or do, are they generally done from people who have contributed? How does that work?    Tim Paul: Yeah. So from the outset really, we wanted to make sure that what we built was owned by the community of designers and developers in government, and was easy to contribute back to. And there’s a couple of reasons for that. One is that we’re, GDS is at the centre of government and that’s really helpful as a way to kind of propagate out best practice and so on, but it does mean that we’re kind of one step removed from the actual end users of citizen facing services and staff systems and so on. It’s really the teams in the other departments that are closest to those users. And so we really rely on them to feedback into the Design System about, about whether components or patterns are working or not. Maybe they’ve found ways to improve upon them, maybe they have ideas for brand new components and patterns that, that we don’t realise are needed. And so like I say, from the very beginning we were trying to figure out ways to, to kind of foster a community of collaboration and contributors.    And so we initially populated the Design System with maybe about 30 or 40 components and patterns that we already knew were needed by government. Some of those we brought in from our previous design tools.    Laura Stevens: Yeah.   Tim Paul: But since then we’ve had about 18 new components and patterns published over the last year and a bit. And I think of those 18, about 13 of them have been external contributions. So things that have been built by people in service teams somewhere else in government, from MoJ [Ministry of Justice] or DWP [Department for Work and Pensions] or HMRC [HM Revenue and Customs] and so on, and then contributed back to the Design System.    And so we from kind of experience with our previous tools, our legacy products, that contribution is difficult and it certainly doesn't happen for free and it doesn't happen at all unless you do a lot of work to facilitate it and so on. So we put a lot of effort into developing the necessary processes and the governance and the assurance so that when people made a contribution, they knew what to expect and they knew the criteria that they needed to meet and that there were people available to support that contribution. And then other people who are available to kind of assure the quality.    So what we’re hoping is this, by this, by making this process really open, it kind of encourages trust in what we’re doing, and it means that the work that we’re publishing isn’t biased, in favour of any one department and so on. And that it, and that it actually reflects the needs of teams in government.   Laura Stevens: So how does it make you feel having so many patterns and contr-and components now being able to be contributed? Because, this, this hard work of making it decentralised, making it open is working.   Tim Paul: It, I think it is working, I think we’ve learnt a lot along the way. We’ve certainly learned that it’s harder than we thought it would be. I mean we thought it would be hard, but it’s even harder than we thought it would be. I think perhaps we were tempted to think in the early days that contribution was like a shortcut to scaling.   Laura Stevens: Yeah.   Tim Paul: That like by opening our doors and letting people contribute, we could grow rapidly and it would like solve all our problems that way. And actually over the last year or so, I think what we’ve realised is that facilitating and assuring contributions is often as much work as doing the work yourself. We should probably have realised that at the time. And so I think it does let us scale but not to the extent that perhaps we thought it would.   So yeah, we think that aside from scaling, there are other real concrete benefits to, and I’m encouraging contribution on one of those, is that when people make successful contributions to the Design System, they tend to be pretty strong advocates so they almost act as like people doing engagement in departments on our behalf.   But also, and perhaps more importantly, the more people from service teams in other departments make contributions to the Design System, the more representative the Design System is of what those teams need. And so it just really helps us make sure that our product is actually genuinely meeting the needs of our users.    If we were doing all the work ourselves in the centre, then, then there’d be a really strong risk that what we were producing was only really meeting the needs of the teams that we were closest to.    Laura Stevens: And I think that leads very nicely on. Because we’re now going to hear a clip from somebody who uses the Design System who isn’t from GDS.   Tim Paul: Ah.   Laura Stevens: It’s from Adam Silver, who previously worked at the Ministry for Justice, or MoJ Digital. So yeah and MoJ is the second largest of the 24 ministerial departments, so it’s a big department.   Tim Paul: Yeah.   Laura Stevens: And yeah, he’s going to talk about using the GOV.UK Design System and also about the MoJ specific Design System as well.    Adam Silver: I’m Adam Silver, I’m an Interaction Designer working at the Department for Education, and previously I’ve worked at MoJ Digital and HMCTS [HM Courts & Tribunals Service] as well.   Laura Stevens: Could I talk to you about your work with the GOV.UK Design System on the service claim for the cost of a child’s funeral, which is a highly emotional service and also one that had to be delivered at pace in 6 weeks in fact. So how did having this centralised system help you in that?   Adam Silver: Yeah so we used the MoJ form builder, which is a tool that lets you create and deploy digital forms live, live to a URL without spinning up your own dev team. And under the hood, that form builder uses all of the components and patterns of from the GOV.UK design system. So that meant we didn’t have to spend a whole load of time thinking about text boxes, radio buttons and all of, all of the good stuff that’s already been solved brilliantly. And we could just focus on the specific needs of our service, and filling in the gaps where the GOV.UK Design System didn’t have a solution for that.   Laura Stevens:  And so in that way, was it saving you time, was it saving you hours of work, what was it helping you with?   Adam Silver: Yeah, it saved, saved a lot of time. Because instead of focusing on all those things we could focus on just the needs of our service. So for example, we needed to think about how to ask users for their bank details because we needed to make a payment for them for their claim. And we also focused on things like how to upload files because they had to provide evidence for their claim by uploading copies of their receipts. And those, those 2 particular components and patterns aren’t covered really in the GOV.UK Design System. So that’s where we could really focus our attention.   And the other thing was that when we were doing an accessibility audit before we launched, we could focus most of our attention on the new patterns that we knew might not be up to the level of quality, or level of accessibility, that all of the other components that, like the text boxes and radio buttons in the GOV.UK Design System.    Just that it’s so, so real, it’s just so good. Just the quality of the guidance, the quality of the patterns, the components themselves is excellent. It plays really nicely into the prototype kit. And when I have worked on department specific design systems, it plays nicely with those ‘cause. So we’ve, we’ve... At HMCTS and MoJ Digital, we had our own department design systems and we had to extend and build on top of the GOV.UK Design System. So that was, that was another really good thing.    Laura Stevens:  Could you sort of speak then to how important having this centralised GOV.UK design system is to different departments across government?   Adam Silver:  Oh yeah, absolutely. I mean we have several services at MoJ that were asking people for their bank details. And during our research there are many many government departments that have many many services of their own that are also asking for their bank details. So there is a lot of duplication of effort there and a lot of inconsistency between them. Not, not major inconsistency but little inconsistencies and those can, those things can, can add up to creating a less than ideal, tricky user experience.    So having that centralised and standardised in GOV.UK Design System adds a tremendous amount of value along with everything else that is centralised in, in the system.   Laura Stevens: How does the community behind the design system help you in your work?   Adam Silver: Yeah, so well, that’s, it’s majorly helpful. It’s one of my favourite things about working in gov [government] actually, is, is the huge design community who are just willing to, to help. On, on Slack, there’s like thousands of people on there and they’ve, there’s always somebody that’s either come across your exact problem or they’ve come across something similar and can help out.   And then the backlog itself, or, or the more specific help around the design system, I mean the team are real-super friendly. You get to know them individually, they’re always there to, to help. And having someone dedicated on support each, each day on Slack is, is massively massively helpful, knowing that you can go to one place to get help is, yeah, I can’t, I can’t just, I can’t commend it enough really. It’s super valuable to me and it’s, I know that it’s been super valuable to other people I’ve worked with as well.    The community backlog is really good because if there isn’t something in the design system then you know that there’s going to be...well there’s a very very good chance that somebody has put their own designs into the backlog. Just some screenshots, just some explanation and then some discussion. And that, that will get you going so you don’t have to start, you’re never, you’re never really starting something from scratch because somebody has always done something. And somebody, sorry. Sometimes somebody has done more than something. There’s, there's a lot of contributions on some of the backlog tickets as well.   Laura Stevens:  So Kellie Matheson, who works at MoJ Digital, also spoke at Services Week 2020 about having two Design Systems and working with that. How do you, how, what’s been your experience of using two design systems at once?   Adam Silver: So it’s not, it’s not the ideal situation. It’s because, the reason why I think design systems appear in departments is, is because, well for 2 reasons. One is that GOV.UK Design System just can’t go fast enough in accepting contributions which is kind of what I was talking about earlier. They’re just not resourced enough I don’t think. It takes a lot of effort to build out a component.   Laura Stevens:  Yeah, yeah, yeah.   Adam Silver:  So that, that’s one reason where a department could move a little bit faster. Quality might be a tad lower but they can move a bit faster. Because they’re not worrying about the needs of the whole of government, they’re just worrying about the needs of their department of the needs of a programme within a department, sometimes that’s the case. And the other reason is because there are literally department specific patterns. But I see it as a temporary solution while, until the GOV.UK Design System can pull those patterns in.    Laura Stevens: And you, on your blog post, you also contributed a pattern along with your colleagues Amanda Kerry and Gemma Hutley, what was that pattern?   Adam Silver:  That was how to ask users for their bank details. So as part of the, as part of the Child Funeral Fund service that we were designing, the main, the main point was that the user is claiming back the costs. So to do that they need to provide their bank details and that way we can, during the claims process, make that payment to them.    Laura Stevens: And what was it like to contribute your own pattern to that, or your team's pattern to that?   Adam Silver: The reason why I wanted to contribute the bank details pattern was because while we were designing the service, there was no actual pattern existing for the bank details. And we looked in the backlog and we talked to people across government and in our own department as well, and there was no, there was no solid example of how to, how to ask for it. There was lots of different good examples but there was no one way. So that’s something that we had to tackle during the 6 week period.    And so it would have been a real, it would have saved us a lot of time if that did, if that pattern was part of the GOV.UK Design System. So we thought ok well look, we’ve learnt quite a bit about it by searching around what other people have done, and we made a decision ourselves for our service. So why don’t we use what we’ve learnt, work a little bit harder and contribute it back.    Laura Stevens: So I’m sitting here with Tim Paul...And so you can ask him anything, what do you ask him?   Adam Silver: Hi Tim, I would ask you how to quantify the value of a design system?   Laura Stevens: So a nice easy question there.    Tim Paul: Yeah, thanks Adam!    Laura Stevens: But I did actually hear there was, I did actually see this was, this was your talk in Services Week 2020, wasn’t it?   Tim Paul: Yeah. Yeah. So first of all, that was really good to hear from him. And yeah. One of the things we’ve always known that we need to do, and any team will need to do, is to somehow quantify the benefits of the thing that you’re delivering. Design systems are no exception. But it is quite hard to do that because of the nature of the service and the products I think. They’re not transactional services, you can’t watch people kind of go through them, people aren’t signed in when they use it and so measuring how many people are using your service and product is tricky enough.   And then quantifying the actual material benefits is also not that easy. It’s all about productivity and that’s quite a hard thing to measure. These aren’t small tasks that can be done in a few minutes where you can, can easily measure how much faster people get. These are tools which help people over the course of days and weeks and months in quite unpredictable and subtle ways.    So we’ve always struggled a little bit. Although I think this quarter we’ve gotten a little bit better at this stuff. And so we were joined by Roxy, who’s a Product Manager in GDS, and she’s really helped us deliver a kind of economic model and, and a business case for how, how much benefit the Design System is, is giving people. And so we did a fair amount of research, we did lots of analysis of things like repos on Github.    And we fed all of this information into an economic model, we worked with an economist called Parri. We, we, we had lots of other data points. Our user researcher Rosie did, at quite short notice, did some really good research where we interviewed around 10 designers and dev-developers from different departments, and we got them to talk about their experience of using our tools. We got them to do the very uncomfortable thing of like trying to, trying to tell us how much more or less productive they were using our tools and not using our tools.   Laura Stevens:Yeah.   Tim Paul: Which is a, it’s a really tough ask. But people did tell us and we got enough data points that we figured taking an average and going with a conservative version of that average was sufficient. And so feeding all of this stuff together, and thinking about how many teams are actually using our products and for how long and so on, we got to a kind of round figure of, we think we’re probably saving the government about £17 million pounds a year right now    And that’s based on the assumption that without the Design System, government would need to spend about that much money to deliver the same services of a similar quality. So yeah.   Laura Stevens: And were you, did you think the figure would be about £17 million or did you...   Tim Paul: Yeah..I don’t know. I guess it was higher than maybe I was expecting.   Laura Stevens: Yeah.    Tim Paul: Yeah. Yeah. But one of the things we’re really keen to do is focus as much as we possibly can on, on the more qualitative benefits of Design Systems.   Laura Stevens: Sure.   Tim Paul: Rather than treating them as a kind of efficiency tool. They definitely do help teams work more productively but what we’re really hoping is those teams use their excess capacity to deliver better services. And so Adam kind of touched on that. Because they don’t have to worry about checkboxes, and radio buttons and headers and footers and making those all accessible and usable, they can spend that time that they’ve saved focusing on the actual service itself, and the content design, and the service design and the policy design and so on. And that’s really where the gains are to be had for individual service teams.   Laura Stevens: Adam also referenced about how there are other individual organisations using their own design systems, they’ve made up their own design systems. Why do you think places have created their own versions?   Tim Paul: There have always been other design resources made by other teams and departments in government, and that should come as no surprise. For the most part these are people with quite similar missions and goals to ourselves.   Laura Stevens: Yeah.   Tim Paul: They’re trying to solve the same problems but at the level of their individual programme or department. And so a couple of years ago when we were initiating this work, we made a conscious decision to, to not treat them as rivals or competitors or in some way a symptom of failure. They’re really just people who are trying to solve the same problem.   And so we, r-rather than go around and try and s-shut them down or anything like that, we made friends with these people, these people are now contributors and we try and work closely together with them    Laura Stevens: And not only is the GOV.UK Design System helping in central government, but it’s also being, helping across the public sector in local government and the NHS. And we’re now going to hear from Emma Lewis, from Hackney, about her experience of using the Design System in a local authority.    Emma Lewis: I’m Emma Lewis, I am the Lead Frontend Developer at the London Borough of Hackney.    Laura Stevens:  What is the London Borough of Hackney doing with design systems?   Emma Lewis:  So we have our own Hackney Design System and Hackney Pattern Library, and both of those are based on top of GOV.UK Design System and GOV.UK frontend respoistry. So we have our pattern library is called LHB Frontend. Which is essentially a copy of GOV.UK frontend which also imports GOV.UK frontend and we build on top of that.    So we have a bunch of different components, some of which are basically identical to the GOV.UK components but they have sort Hackney, ‘Hacknified’ styles or small colour changes, spacing tweaks, things like that. We have some components that are actually identical to GOV.UK and some components that are completely new to Hackney because they're more local government focused.   Laura Stevens:  What have been the benefits to you working in local government, for using a central government design system?   Emma Lewis:  I mean it’s been huge. So having all of these things just out of the box sort of we can use, it’s such an enormous time saver. But also having things like we, you know, we know they are accessible. So it means the services that we’re providing to residents and staff are so much better than they would have been otherwise.    Laura Stevens:  And I think a lot of people respond to with the GOV.UK Design System is also that community element of it. Has that helped you as well at the council?   Emma Lewis:  Enormously. There’s no-one else really experienced at frontend development that I work with, and having that community of people who I can ask questions to, is such a positive thing. And likewise I am so grateful for the GOV.UK Design System that it means I want to contribute and I think other people feel like that.    So I’ve contributed a couple of pull requests that are like really really tiny minor changes but feels good to do that. And it’s something that I want to do. And I think you see that with other people in the community who aren’t necessarily working centrally at GDS but have benefited from it so want to contribute something.   Laura Stevens:  Why is having a design system a good thing for local government?   Emma Lewis:  It’s...there are lots of different reasons. The main, the first reason is consistency. So it means that you know, any of our products that use that design system are going to look the same and that means, that’s really good for lots of different reasons. It means we’re not duplicating code in lots of different places. So you know, if something changes we don’t need to update it in loads of different places, there’s just a central place where all of that stuff comes from. And that’s something that developers love.   Laura Stevens:  Yeah.   Emma Lewis:  But also I think accessibility is a huge thing. The time and resourcing that goes into making a design system like GOV.UK, like I’ve never seen the amount of effort that goes into a component be put into that kind of thing outside of a design system.    Laura Stevens:  Yeah.   Emma Lewis:  And so making sure that it is accessible means that it’s usable by all of our residents and that’s really important. And we, one of our missions at Hackney is to create digital services that are so good that people prefer to use them.   Laura Stevens:  Yeah.   Emma Lewis:  And in order to do that, they need to be available to work for everyone and that’s like incredibly important.   Laura Stevens:  So this is a bit of a, like a retrospective question. What do you wish you knew, or to anybody who is listening from a local authority, from a local borough, before you started creating the Hackney Pattern Library?   Emma Lewis:  I think 2 things that spring to mind. One of which is how important your decisions are when you start doing something like that. So I think I hadn’t appreciated how difficult it can be to change things down the line. And this is something that...so Nick [Colley] and Hanna [Laasko] who work on GOV.UK frontend actually we’re really kind and came into Hackney to talk to us about the design system. And they were talking about how hard it is, or how bad it is to make breaking changes.   Laura Stevens:  Yeah.   Emma Lewis:  So you know, changes to the design system or pattern library that are going to break things for users of the older versions. And that’s something that I wasn't, I hadn’t really thought about much until that conversation. And now, we’re sort of 6 months into our first version of our pattern library, and I’m starting to see, ‘oh I wish I’d done that differently’. And you know really feeling empowered to take the time at the beginning and think about those considerations about how you’re doing something and whether it is the right thing and what possible use cases there might be down the line, can be really helpful.   Laura Stevens:  So how, what are people using it, what sort of stage are you at?   Emma Lewis:  So I’m doing some work at the moment with our mapping team, who create all sorts of maps for residents and for staff to look at, from things like where water fountains are, are in the borough to planning applications and all sorts of different things. And we’re coming up with, I suppose sort, it’s sort of similar to a design system in a way, we’re trying to come up with this sort of map template that we can use to show all different kinds of data. And I was just showing them really quickly yesterday how to use the design system to put a header and footer on the page, and their faces were just like lit up. It was so exciting that this was suddenly all available to them.    Like using the GOV.UK design system has been an incredible time saver. Like I can’t, we wouldn’t have a pattern library now if we’d had to build everything from scratch. It just. We have so many different projects on and we don’t have the people to build something like that, and by having that, it’s mean that, not only that we can use it on projects going forward, but we’re also massively reducing the amount of time it takes to build all those individual projects as well. So it’s been, it’s just been enormous in terms of the time it saved and like I said, the community around it.    Laura Stevens:  Yeah.   Emma Lewis:  The support that’s been provided with it.    Tim Paul: That was really really nice to hear that. It’s so, so gratifying I think to all of us on the team when other people reuse our work.    Laura Stevens: Yeah.   Tim Paul: It’s one of the best things about working in government and in the public sector is that we can be happy about the fact that people are stealing our work. In fact we kind of strongly encourage it. So yeah, that’s, that’s great. It’s, it’s doing exactly what we hoped it would do.    So we’ve known for quite a while there’s huge potential beyond central government for, for the work that we’re doing, not just ourselves but alongside our contributors, to, to benefit local government and even as far as international governments. We’ve, we’ve got I think we know about 5 different local authorities which are in some way using GOV.UK Frontend, and we’ve got a couple of other governments from other countries who are using our work as well. So this is really really good.   Laura Stevens: And in both those clips, both Emma and Adam, they both spoke about accessibility and how having it tested to the level AA of the Web Content Accessibility Guidelines or WCAG.    Tim Paul: Yes.   Laura Stevens: Is that right?   Tim Paul: That’s correct, yeah.    So this is, this has turned out to be a huge driver I think for adoption of the Design System because there this standard called the Web Content Accessibility Guidelines, it’s been around for a while, it’s in version 2.1 now. But the thing that has changed recently is that meeting level double A of that standard has now become an actual requirement, not just of central government services but the whole of the public sector by this September.    And so suddenly there’s a real strong need by teams everywhere to make their services fully accessible. And that’s pretty difficult. There’s lots you can do it make it easier like building in accessibility from the very beginning is probably the best way you can make your life easier here. Retrofitting accessibility is, is always a terrible experience for everybody.    But it turns out that making even simple things like buttons fully accessible across the full range of assistive technologies, devices and browsers, is actually pretty involved, difficult work. You’ve got lots of testing to do, you’ve got, the state of assistive technologies at the moment is still probably not as mature as it could be, which means there are lots of weird little bugs and kinks.   Laura Stevens: Yeah.   Tim Paul: Funny little idiosyncrasies across all the different technology stacks. And so the work that we do in the centre is to do all of that testing and iron out all of those bugs and figure out how to make these things work across all of the assistive techs that we know that people use. And that level of work, that depth of work is probably not a thing that an individual service team could or should be spending its time doing. They’ve got the full service to worry about and they really shouldn’t be spending the amount of time that we can spend on, on making low level components fully accessible.    So it’s one of the things I’m happiest about because it’s something that we can really contribute to.   Laura Stevens: And in, you mentioned as well that we’re not only helping central government, local, NHS but we’re also going abroad as well. And in March 2019, the New Zealand Digital Service published a blog about how they used the GOV.UK Design System to help create their own. So, and they had a quote in there saying: “We decided not to reinvent the wheel so we’re building on the GOV.UK Design System, a system with years of development. It’s a mature and proven Design System with full rigour and accessibility and testing”. So what does having that sort of reach and international impact feel like for you and the team here at GDS?   Tim Paul: It’s really nice, it’s kind of flattering. Yeah it also feels a little bit scary.   I think Emma alluded to the issue of having dependencies and breaking changes and things like design systems. And that’s a thing that we’ve experienced as well. So if you’re working on a service team in an agile environment, then the idea that you can iterate rapidly and fail fast and all of that, it’s great, it works really well. It doesn’t quite translate when you’re building a central code resource because if you’re iterating rapidly, if you’re failing fast, if you’re making lots of breaking changes, then you’re disrupting the work of everybody who’s relying on your code base. And so we end up being a lot more conservative, we end up moving slower and at a much measured kind of careful pace. And that’s because we are intensely aware that everybody using our tools is going to be disrupted by any breaking changes we make.   And so when we hear that you know, another country or local government authority is using our service, it’s really really good but it really hammers home to us how careful we have to be not to break things for them as well.   Laura Stevens: Do you think there’s a way of fixing that? Or is that just an inherent problem with having a central design system?   Tim Paul: I think probably the way to address that challenge is to not try to create some uber design system for the world, which would be the egotistical response to that challenge.    You know the internet is supposed to be made up of many parts loosely coupled, and that’s what we should be trying to do here. So making sure that people can use our tools as the foundation for the things they need, and that we have nice productive feedback mechanisms between, between those. That’s probably the right way to approach this.   Laura Stevens: Is there anything where you’ve seen the Design System used in a way that you just never expected it to be used, or it popped up somewhere that you...   Tim Paul:  We’re, we’re sometimes asked about doesn’t, don’t, don’t these products make it really easy to make fake versions of GOV.UK, which is a really valid question. And the answer is yes, they do. They make it easy for anybody to make things look like GOV.UK. But to be honest if your motivations are to trick people, then it’s always been pretty easy to make fake versions of a website.    Laura Stevens: Yeah.   Tim Paul: So we’re not making it that much easier for the scammers, but we’re making it a lot easier for the service teams who are building legitimate services. But yes, every now and then we see, we see a dodgy looking GOV.UK site and we see our own code in there, and that’s kind of weird but you know there’s a whole bit of GDS which is dedicated to spotting that stuff and getting it taken down so.   Laura Stevens: So thank you so much to Tim to coming on today and also to Emma and to Adam for talking about the GOV.UK Design System. And you can listen to all the episodes of the Government Digital Service Podcast on Apple Music, Spotify and all other major podcast platforms. And you can read the transcript of Podbean.  So thank you again and goodbye.   Tim Paul: Thank you.

GUEST BIO: My guest on today’s show is an internationally recognized author, speaker, blogger and sometimes teacher and consultant.  He has been working with the web since late 1993 and is recognized as an expert on the subjects of HTML, CSS and web standards.   He is currently a technical lead at non-profit organization Rebecca’s Gift and is also co-founder of An Event Apart, a web design conference for UX and front-end experts.   EPISODE DESCRIPTION: Phil’s guest on today’s show is Eric Meyer. He has worked in the IT industry for more than 25 years. Today, he is a teacher, designer and consultant who is a recognized HTML, CSS and web standards expert. He also has a working understanding of XML, XSLT, JavaScript, and related technologies. Eric is also the technical lead for the non-profit organization Rebecca’s Gift and the co-founder of An Event Apart, an interactive conference targeted at designers, developers and front-end experts. He is also the author of several CSS books and the founder of the css-discuss mailing list, as well as a conference speaker. KEY TAKEAWAYS: (1.14) – The very first thing I wanted to ask you about really was the non-profit organization Rebecca's gifs. Could you maybe give us some background about that organization and your involvement? Eric explains that his daughter, Rebecca, died from brain cancer, at the age of 6. One of the things that helped him, his wife, and his surviving children to recover was to go on a special trip together. A few months after Rebecca’s death they took a trip that the kids had kind of planned. It helped them a great deal. So, his wife decided to set up Rebecca’s Gift to help other families to do something similar. They help families, who have lost a child, to take their other children on a trip. It provides them with a chance to get away from everything and reconnect with each other. Eric is the chief technical officer for the organization. His wife takes the lead and Eric looks after the website and the technical side of things. (2.23) - Where can people find out about it? The website is http://rebeccasgift.org/. Eric goes on to explain that, currently, they are US-based. But, people can still go to the website, read about the organization and make a submission. (3.07) - So in terms of your other activities, An Event Apart is something else you're very much involved in. Could you maybe give us a bit of an insight into that? Around the turn of the millennium, he and Jeffrey Zaltzman were attending and speaking at a lot of conferences. Unfortunately, the content was not that great. It did not really speak to people like Eric and Jeffrey. They were designers as well as developers who were not interested in simply slamming out websites. Instead, they wanted to create sites that were user-friendly, forward compatible and accessible. None of the conference speakers shared information that was truly relevant to the way they worked and what they produced. So, they decided to remedy that situation. Eric and Jeffrey put together a one day show and took it around a few US cities. People liked it but often said that they wished it was for more than one day. Over time, they have been able to respond to that request and turn the An Event Apart into a 3-day interactive conference. The show is designed to enable developers to explore and for designers to find out more about development. Plus, of course, for those who already do both. They cover the entire spectrum, including UX and information architecture. It is not just about the cool stuff. The essentials like CSS Grid and Flexbox are also covered. (5.26) – How many cities do you expect to be arranging events for, this year? Eric says that by the end of the year they will have done the show in 6 cities. At the time of recording, the Seattle event was behind the team and the Boston event was next on the agenda. With Washington DC, Chicago, Denver, and San Francisco still to take place before the end of the year. (6.18) – Can you please share a unique career tip with the I.T. career audience? Eric explains that there really are no gatekeepers. There is nobody in IT that can make or break your career. Nobody has the power to shut you out of web development. The only person that can stop you is yourself. (7.37) – Can you tell us about your worst career moment? And what you learned from that experience. Eric worked on the Y2K switch over. For a joke, he and another colleague decided to make the university webpage look like it was created in the 1900s when the clock struck midnight. They put together a page using typography from the era and included the message “as you can see the server thinks it is 1900.” They thought it would be fun, but they did not tell anyone what they were planning to do. The page went live, the press got hold of the story and all hell broke loose. This did not go down well with the administration. Eric’s boss was told to fire him. Worse his boss’ manager was told to fire him, as well. Fortunately, neither of those things happened. However, Eric still feels bad about inadvertently putting his boss’ job at risk. (10.00) – What was your best career moment? Eric went to Case Western Reserve University. While he was there two of his professors asked him to put two encyclopedias they had written online. It was a big project, which is really proud of managing. Now, anyone who is interested in the history of Cleveland, Ohio can access a huge body of material and do so for free. (12.40) – Can you tell us what excites you about the future of the IT industry and careers? Eric is really excited about the way CSS Cascading Style Sheets is changing things and the rate at which it is growing. That is what is exciting him about the sector of the IT industry he works in. Looking at things more generally, the fact that people involved in the IT industry are starting to have a conversation about ethics is good to see. Mike Monterio has just published a book about design ethics in which he takes a strong stand. We need to think about the impact doing X can have, outside of the purpose we have built it for. Developers need to ask themselves how what they are creating can be abused. (15.25) – Do you think this will result in new roles within the IT industry? Eric hopes that one day we will see appointing a chief ethical officer becoming the norm. Dumping a load of data into a recursive neural network and hoping nothing goes wrong may be OK in a closed environment, as a way of exploring the possibilities. But, it is not OK to deploy that stuff to the public. You need something in place to make you pause, think about what could go wrong and decide if you should still proceed. (16.44) – What drew you to a career in IT? For Eric, initially, it was the fact that he could make good money. He had been using computers since he was 7, so getting into the IT industry was a natural progression. (17.31) – What is the best career advice you have ever received?  When Eric asked Jeff how he could get to be a conference speaker, he said: “write a book”. Eric did. After that landing speaking gigs was easy. Even if you do not want to be a conference speaker, it is still a good idea to write about what you know. You do not have to write a book to do that. Running a blog is just as an effective way to put yourself out there and let people know what you are about. Eric has known people to be hired because someone liked a blog post they wrote. (18.20) - Conversely, what is the worst career advice you've ever received? One of his managers, at the university, told him to “stop playing with that silly web stuff.” Fortunately, everyone ignored him and carried on learning and working with HTML. (18.49) – If you were to begin your IT career again, right now, what would you do? Eric says he would go to code school or get a degree in computer science. But the biggest thing he would do differently is to focus on finding work that really interested him. So, he could stay engaged enough to dive deep, truly understand things and share what he was learning. When he finally started sharing what he knew, his career took off. Today, he would get involved in GitHub, Medium, and Stack Overflow far more quickly and deeply. (20.02) – What are you currently focusing on in your career? Eric wants to become a better leader. He is also teaching himself more JavaScript, he wants to make sure he can understand the emerging JavaScript technologies. (20.42) – What is the number one non-technical skill that has helped you the most in your IT career? Being an effective communicator is Eric’s most important non-technical skill. He knows he is good at doing it in writing and he is working hard to become just as good face to face. For example, in training situations, when he can see from people’s faces that he has lost them a bit, he now doubles back and explains things differently. (21.26) - What do you do to keep your own IT career energized? Eric finds that rotating through a stable of things that need his attention keeps him engaged and motivated. If he starts feeling a bit burned out, he switches track for a while. Doing something different re-energizes him, enabling him to switch back and start moving forward again. (22.13) - What do you do in your spare time away from technology? Eric enjoys carpentry. He started out doing what they call rough carpentry. For example, he built a coop for his chickens. Now he has some experience, he is getting into finer woodworking.  (23.10) – Phil asks Eric to share a final piece of career advice with the audience. When deciding what tech to learn next, think about what you want to do with it, not what you want to do in it. Ask yourself what interests you. For example, would you like to make servers run faster? Or do you want to connect people? Asking yourself what differences you want to make to the world will naturally point you in the right direction. It will make it easy for you to identify what technologies you need to learn. That is how he and Jeff ended up putting together the An Event Apart conference. They saw an issue, wanted to solve it, so, went out and learned what they needed to know to run their own conferences. When deciding what tech you will learn next, you need to take a similar approach. Learning something with a purpose is always a far more effective and interesting way to learn. BEST MOMENTS: (6.33) ERIC– "There's nobody in IT who can make or break your career other than yourself," (14.35) ERIC– "When people create things, they need to ask themselves, how could this be abused?” (18.26) ERIC– "I know people who have never written a book, but have been hired by somebody because of a blog post they wrote" (21.46) ERIC– "Communication, which people call a soft skill, is one of the hardest to master. It takes practice." CONTACT ERIC: Twitter: https://twitter.com/meyerweb   LinkedIn: https://www.linkedin.com/in/meyerweb   Website: https://meyerweb.com/   Rebecca's Gift: http://rebeccasgift.org/

Guest: Dillon Kearns: @dillontkearns | GitHub | Incremental Elm In this episode, Dillon Kearns joins the show to talk about techniques for experimentation with Elm, making those experiments safe, the concept of mob programming, why you would want to experiment with Elm in the first place, and how you too can begin to experiment with Elm. Resources: Grant Maki's talk on experimenting in your team "Types Without Borders" by Dillon Kearns @ Elm Conf 2018 Dillon's Elm GraphQL library How Elm Code Tends Towards Simplicity by Dillon Kearns The CSS as ByteCode Talk by Richard Feldman This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 114. My name is Charles Lowell. I'm a developer here at the Frontside. With me today as co-host on the show is David. Hello, David. DAVID: Hey, guys. CHARLES: David is also a developer here at Frontside and we are going to be talking about something that we've been talking, I guess a lot about recently and we're talking about Elm. I think we first started talking about this several years ago and then it kind of simmer down a little bit but recently, it's been top of tongue. With us to talk about Elm today is Dillon Kearns. Welcome Dillon. DILLON: Thank you so much for having me. CHARLES: I understand that you are a full time Elm consultant. You have a background as a Lean and Agile coach but have recently transitioned to doing Elm consulting full time. Now, what exactly does that mean in 2018 to be an Elm consultant. DILLON: Actually a lot of my motivation for getting into Elm consulting in the first place is I kind of realize that Elm to me is just an extension of the things that I was passionate about with Agile and software craftsmanship. I'm trying to help teams have a better experience with their code, make it more maintainable, make it easier to change, make it easier to drive things based on customer feedback and I really believe that Elm helps people do that. I used a lot of the background and experiences that I've had with Agile and Lean coaching and a lot of those same skills, in order to help organizations adopt Elm. One thing I've seen a lot of teams struggling with is trying out a lot of different frameworks. I've encountered teams that have spent months, very painfully trying out different frontend frameworks and having trouble coming to consensus about that. One of the things that I think really helps address that is having an experimental and iterative approach, that you can really use the scientific method to focus on learning, rather than getting it right the first time. I think that there's really a need to help teams through that process of introducing a new frontend framework like Elm, so that that's why I've gone into full time Elm consulting. CHARLES: That's an interesting process. It sounds like you really need to be constantly sending out spikes, doing research on whether it's Elm or some other technology to help you kind of bridge the chasm to the next generation. How do you actually do that as an organization? My guess, this kind of a question independent of Elm but maybe we can talk about how you see that play out in the context of Elm. DILLON: Right and actually, for any listeners interested in that question, I would really highly recommend Grant Maki's ElmConf talk from this year. He spoke about exactly that topic and it was at ElmConf that it's relevant whether your team is considering Elm or looking at other frameworks. I think that the key is you need to get good at experimenting in a way that's low risk and in a way that you can be constantly learning and seeing how these different technologies fit in your codebase and fit for your team. There's a quote that I really like from Woody Zuill. Have you guys heard of mob programming before? CHARLES: I heard of mob programming from a paper by Richard Garfield a long, long time ago, almost 20... I don't know if it's the same concept. DILLON: Yes. It gained a lot of momentum these days. Mob programming is essentially pair programming but with more people involved. I've really enjoyed that process actually. I think it's actually a great way to experiment with different technologies because you get all of the minds together and it's a very good way to kind of transfer knowledge and explore things together but Woody Zuill talks about mob programming and he likes to ask the question, "Why did we begin doing mob programming for the team at Hunter Industries that originally started mob programming?" People would give answers like, "Because it cuts out code review from the process because you have lots of eyeballs on it in real time," or, "Because it reduces bugs," or, "Because it gives you better quality code. It gives all the best ideas into the product in real time," and all those things are valid points that are really good benefits of mob programming. But he says those things may be true but actually, they're not why we tried mob programming. The reason we tried mob programming was because the team wanted to try it. That's a really important point. The team needs to be experimenting with things that they're passionate about and they need to be exploring things on their own terms. But with that said, another lesson from that story of kind of his team at Hunter Industries discovering mob programming is that the team didn't discover mob programming in a vacuum. Really, the team discovered mob programming because the team became really excellent at experimenting and evaluating those experiments and then, they like to talk about this phrase that Kent Beck coined, 'turn up the good.' When something is working well, we often focus on the negative things and trying to eliminate those things but what happens if we take the things that are working well and 'turn that dial up to 11.' CHARLES: Yeah, I love that. I remember in the kind of the original layout of extreme programming, talking about how I really just wanted to turn up all the things that were working for 11 or to 11, so testing, refactoring, incremental releases and things like that. DILLON: Exactly. CHARLES: I actually had one question that's maybe a little bit of a diversion. This is actually the first time I've heard of mob programming. It's definitely not the same sort of mob programming I learned about in Richard Garfield's paper. I think it was more referring to massively distributed open source in the form which is really kind of commonplace now that happens on GitHub. I think it's maybe, an obsolete definition of mob programming but how many people would be in a mob like two, three, four, five, six, seven, 10? DILLON: That's a great question. Really, the answer is of course, it depends. That's a consultant's favorite answer but it really does. My rule of thumb is I find it usually three people is a very nice size for a mob. I find that mobs tend towards around three or four people but that being said, it's important to note that mob programming is all about this idea that what is the true cost of programming. I think that often we look at programming as the act of writing code, initially and that's a very limited way of looking at coding. Because of course, 90% of our effort is spent maintaining code, making decisions around code, reproducing bugs, fixing bugs, communicating with customers about bugs -- bugs are extremely expensive -- the farther out they get, until eventually they get to the point of a customer discovering them, bugs are in extremely expensive part of software. If we can minimize bugs, that's very valuable. When you look at programming on this bigger scale and look at the bigger picture of programming, then you realize that you may be able to get one person to write the code faster but then, that person needs to code review it. That person needs to go and ask somebody question down the line when they don't have context because they weren't involved in the decision making. For example, maybe there's a UX person who doesn't have context on certain choices that were made, so there's a lot of churn, so you can kind of eliminate that churn by getting all the relevant people involved right away and that's the idea. In my experience with mob programming, it works really well to keep kind of a core of around three people. Sometimes, somebody goes up to have a conversation with somebody, take a break or answer somebody's question, maybe somebody from another team has a question that type of thing and so, the team can keep coding as a pair or whatever. But ultimately, the idea is that you get faster because you're building up this shared context and you're not spending as much time down the line answering questions, doing code reviews and things like that. CHARLES: Right. I see. DAVID: That kind of matches with my experience. Mob programming on previous teams, the way we had it set up is there was a regular mob programming chat session that the whole team was invited to but it was optional. You can just show up if you wanted to and really, that sort of made it so that there was a set of people who regularly attend -- three to five people in a session -- and they were the core group, essentially. DILLON: Right. That's another great point. Invitation is a powerful technique. If you're kind of mandating the people try an experiment or work in a certain way, ultimately it's much more powerful to let the team experiment on their own and follow their passion and they'll discover great things. It's about experimenting, rather than choosing specific experiments. While we're on this topic of kind of the real cost of coding, I think this is a good point to talk about this quality in Elm because, I think that this is one of the things that really motivates me to use Elm myself and introduce it to others is that, I think that Elm really get something about programming where there's a sort of superficial ease of certain techniques that Elm kind of goes beyond and says, "Actually, let's optimize for a different set of things that we think make code more maintainable and more delightful to work with in the long run." CHARLES: I wanted to also transition between, we were on a little diversions on mob programming but do you use mob programming as explicit technique for introducing Elm when a team is considering adopting it? DILLON: That's a fantastic question. I absolutely do. Of course, I honor the ways of working in a particular organization or team. I think that's important to do but I do strongly encourage using mobbing as a technique for knowledge sharing and when I'm on-site with a client, I find it extremely powerful as a technique for knowledge sharing and also, let's say you do an experiment, somebody is off in a corner and they're trying out Vue.js or they're trying out Elm or they're trying a particular coding technique. Then they come back to their team and they say, "Hey everybody, I tried this great thing," and now they have to spend this time convincing everybody and saying like, "Wait a minute. You didn't try this, you didn't try it that way. It wouldn't actually work in our context because of this." I think that it's very powerful to have everybody kind of involved in that process so that you can evaluate it together as a team. CHARLES: Because the thing is like, when you experience win or you experience fail, it's a very visceral feeling and that's the thing that sells you or turns you away. You can argue until you're blue in the face but words have a very limited capacity to convince, especially when compared with like physical and emotional feeling. It sounds like you can get everybody to have that shared experience, whether for the good or for the bad, you're going to arrive at a decision, orders of magnitude more quickly. They have to rely in conviction of that decision spread around the team. DILLON: Exactly. I think that hits the nail on the head and you say that we have this sort of skepticism of arguments from theoretical conversations, rather than 'show me the money,' but it's actually, try solving a real problem in this and that's exactly as it should be. I think that's one of the big antidote from this problem that I've seen in a lot of environments, where there's this analysis paralysis, especially with the state of the JavaScript ecosystem these days. I think that one of the keys to improving that situation is to get good at trying things, rather than theorizing about things. We have a tendency to want to theorize and when we do that, then we say, "Can it solve this problem? Can it solve this problem? Can it solve that problem?" You can talk about that until the cows come home but it doesn't get you anywhere and it doesn't really convince anybody of anything. The key is to find very small experiments and what I really recommend and what I'm dead focused on when I'm initially working with a client is getting something into production. Now, that doesn't mean that you need to have a road map for turning your entire application into Elm. In fact that's the whole point, is that you're not trying to do that. The point is you're trying to get as realistic of an experience as possible for what problems might occur if we do this? Will the team enjoy working with this language? Will it work well with our built pipeline? Will there be any unforeseen issues? You don't know until you actually try it, so you've got to try it and you've got to try it in tiny, tiny steps and low risk experiments. CHARLES: Right but you've got to try it for real. You don't want to try it with a TodoMVC. DILLON: Exactly. It needs to be meaningful, to really have a good understanding of what it's going to be like. CHARLES: I would say that I tend to agree but I've definitely encountered the counterargument and I also think this counterargument makes sense or perhaps where the pushback lies is if I'm constantly experimenting, then what I'm doing is I'm internally fragmenting my ecosystem and there is power in similarity. Any time you introduce something different, any time you introduce one fragment, you're introducing complexity -- a mental complexity -- like maybe I have to maintain my Elm app and I also have to have my Legacy... Or not Legacy, I've got my other JavaScript tool kit that does it in one way. Maybe I've got a couple of more because I've run these other experiments. I'm not saying that there is one way but there is power in uniformity. There is power in diversity. Where do you find the balance? DILLON: Those are all excellent points. To me, I think really the key is it's about the scientific method, you could say. The thing with the scientific method is that we often forget the last part. We get really good at hypothesizing about things. Sometimes people leave it at that, which we kind of just discussed. Sometimes, people go past the hypothesizing stage and they actually run the experiment and that's great. But then, the majority of people, if they get to that point, will forget to do the last step which is to evaluate the results. I think the key here is you need to be experimenting and this is what it means for it to be a low risk experiment. It means that you're not setting yourself off in a direction where you can't turn back. You want to set it up in such a way that you can turn away from it with minimal cost. One of the things that is really helpful for that is if you build a tiny, independent, little widget in your application, try building that in Elm. Some people will do that with a little sort of login badge in the corner of their application. One of the teams where I've introduced Elm at a Fortune 10 company, actually where we introduced Elm, we started out with just a tiny little table in one page and if we wanted to back that out, it would have been trivially easy but we decided that we wanted to go in further and invest more. CHARLES: That makes a lot of sense. Effectively, you need to have a Plan B. Don't sync all of the available time that you have to invest in an experiment. Make sure that you have a Plan B and if you need to do this widget or this table in Angular or React or Ember or whatever, you are thinking about that -- how would that work. DILLON: Exactly and the thing with experiments is the purpose of an experiment is not to build something. It's to learn. I really like this kind of ethos of lean startup, which I think is really getting much more into the mainstream in the software industry, which is a wonderful thing. The idea of lean startup, the kind of core concept is this idea of validated learning. Basically, in an environment where there's uncertainty, which is pretty much most of the things you're doing in software, the main goal is you're not shipping a product like you would be if you're trying to manufacture cars as quickly as possible. The main thing that you're producing is what they call 'validated learning' and so, you want to minimize the amount of time it takes to validate or invalidate your assumptions about something and then, you want to make it as cheap as possible to move on from that. CHARLES: I like that. So if you're going to organize your development process around this principle or maybe not organize it but integrate it into development process, how do you know that you're conducting a healthy number of experiments, versus I may be conducting too many experiments? Is there a metric that you can look at? We need to have this many experiments running at all times or this is just too many or something else. DILLON: That's a really interesting question. I think I would tend to think about that more again, as looking at the way the experiments are run, rather than 'are there too many experiments?' That's just not a problem that I've seen there being too many experiments. The pain that we tend to really see in environments where experiments are hurting teams is the way the experiments are being done. It's hard to backtrack from those experiments and as you were saying before, you kind of put yourself down this path where you can't walk it back and you create this sort of rift in the way the code is being written, which makes it more difficult to work in that codebase. The thing with experiments is they can have really big payoff. Now, you want to make sure that you're not just going in and picking up every shiny object that you see. One thing that can keep you honest with that is if you're kind of coming up with a hypothesis before you start. If you're saying, "This is the value to our business and to our team if we attempt this thing and this is what will prove that it seems to have that value and this is what will tell us, 'Actually, it doesn't have that value and we should drop it and cut our losses.'" CHARLES: That's a great heuristic. As you're saying and imagining how that might have saved my bacon in the past because I've definitely made the mistake of playing with too many shiny objects and picking things because I didn't fully evaluate what I thought the value. I was explicit with myself about what is the value that is going to bring to this project or this business. I have a theory about it but I am not thinking what is my hypothesis and how am I going to validate or invalidate? I'm thinking, I've got a short term pain that I'm experiencing and I'm grasping for this thing, which I think will solve it and I'm not properly evaluating how it's going to affect me long term. DILLON: Right and that could be a great team practice to play around with is often, teams will kind of come up with action items out of retrospectives. One thing that I think can be really beneficial for teams is to kind of flip that notion of doing action items which again, it's really just doing the middle part of the experiment where you're conducting the test but you cut out the hypothesis part and the evaluation part. Try to bring that into your team's retrospective and try to have explicit hypotheses in the retrospectives and then, in the next retrospective, evaluate the results. CHARLES: All right. I will definitely keep that in mind but this feels like a fresh take on kind of how you manage software development that I haven't encountered too much, being more scientific about it. It sounds like science-oriented development. DILLON: Right. DAVID: I like that. DILLON: There are a lot of buzzwords these days in software development, in general and it's really becoming a problem, I think in the Agile community but really, what it boils down to is these basic elements and basing decisions on feedback is one of those fundamental unit. You can call the scientific method, you can call it lean startup and validated learning, you can call it agile, you can call it whatever you want but ultimately, you need to be basing things on feedback. I think of it almost like our nerves. There's actually a disorder that some people have, which can be fatal, which is that their nerves don't tell them when they're feeling pain. I think this is a great analogy for software because that can happen to companies too. They don't feel the pain of certain decisions not landing well. Because they're not getting feedback from users, they're not getting feedback from metrics and recording, they're not getting feedback from doing that final evaluation step of their experiments, so when you fall on the ground, a small cut could be extremely harmful because you don't know the damage it's doing to you. CHARLES: I think that is a good analogy. One of the things that I'm curious about is we've been discussing a lot of techniques for experimentation and how you can integrate that into your process and how you can make your experiments safe, so let's talk a little bit about -- first of all, two things -- why would I want to experiment with Elm in the first place? Because ultimately, that's why we're here and why we're having this conversation. What's compelling about it that would make me want to experiment? And then how can I begin to experiment with Elm? DILLON: I actually just published a blog post yesterday. It's called 'How Elm Code Tends Towards Simplicity.' To your question of why would a team consider Elm, I kind of talk a little bit in this blog post about a case study at a Fortune 10 company where I introduced Elm to a few of the teams there. One of the teams there, we had actually seen an Angular project that they had worked on and often, in an enterprise environment, you have projects moving from one team to another. I actually had my hands on this Angular project. It kind of moved over to another team and we were experiencing some major pain trying to make changes in this codebase. Even making the simplest change, we were finding that there were a lot of bugs that would be introduced because there's some global variable. There's some implicit state. Sometimes, it was even reaching in and tweaking the DOM and really, the topic of conversation at our team lunches was how afraid we were to touch this codebase. Fast forward a few months and this team was asking my advice on picking a new frontend framework and I introduced them to Elm. They took a run with it and it was pretty remarkable to see this same team that had really struggled with AngularJS and they didn't really have a strong sense of what were the best practices. They weren't getting any guidance from the framework itself and the tooling around it and they actually loved the experience of working with Elm because they were saying, "This is amazing. Maybe it takes a little time to figure out how to solve a particular problem on Elm but once we do, we know that we've done it in a solid way." One of the things that I think is most powerful about Elm is that it keeps you from shooting yourself in the foot. I think that's a really good headline kind of summary of what I love about Elm. For example, tweaking the DOM. Now, it might seem like a pretty obvious thing that we just won't tweak the DOM and that's fair enough. That might not be a problem for a lot of teams. People wouldn't even reach for that technique because they're disciplined about it. But at a certain point, you start taking on enough things and then go from kind of those basic things that are going to make your code more unreliable and unsafe like tweaking the DOM and you start getting into the realm of best practices. There's so much discussion these days in the JavaScript community about best practices, which is great. It's great to discuss that but my concern is that there's a new best practice each week and the team has to agree on it, you have to find techniques for enforcing it, people have to make sure that these best practices are being followed in code reviews. Then when you look at a given piece of code, you have to trust that those best practices are being followed, so it requires a lot of work to make sure, in your reducers, in redux that you are not mutating anything. With Elm, data is just immutable. That's just how it is. There are a lot of these kind of things that are baked into the language and the expressivity of the type system allows you to bake in your own constraints. One of the things that I find really compelling about Elm is its design really prevents you from shooting yourself in the foot and it gives you tools for making sure that you take it even a step further and it helps you enforce these best practices at a compiler level. CHARLES: Now what's interesting here is it's almost like the opposite tension of experimentation is a work, right? like here, we have an example of uniformity being the more powerful track but then inside the actual macroscopic process, you want a lot of experimentation and diversity. But at the microscopic level, inside your application, it sounds like you want less experimentation and you derive a lot of strength from that but -- DILLON: That's a great point. CHARLES: -- Experiments that are possible, yeah. DILLON: I think that there is a lot of pain these days in the JavaScript community. We hear people talking often about JavaScript fatigue and it's a real thing. It takes a lot of work to stay on top of the latest best practices and frameworks and that can be a lot of fun. I love learning about the latest new frameworks and tooling but ultimately as you're saying, we don't want that experimentation so much about the fundamentals. We want some dependable, solid fundamentals and then we want the experimentation to happen within there. I think that's exactly what we see in the Elm ecosystem. We have a single kind of data store or way of managing state in Elm. It's called the Elm Architecture. In fact, it's what Redux is based on and it worked extremely well and you don't have to experiment with different data stores in Elm because that's just what Elm code looks like. Now, if you want to experiment in Elm, then there is a lot of innovation happening. One of my favorite things about Elm is that the compiler and its expressiveness has sparked a lot of creativity. One of my favorite things about Elm is the library called Elm UI. Actually, a client that I'm working with right now, it's a really interesting case study. They are kind of a very small startup. They just kind of branched off of a larger startup. They're building some tooling for this ecosystem. They were engineers at a company called Procore that does cloud document management for construction companies. They wanted to get a product-ready for a big conference for their potential clients. The reason they brought me in to help them was because they wanted to reach this ambitious target of being able to do a demo of this brand new product at this conference and they wanted to iterate very quickly. One of the things that really drew them into Elm in the first place is this library Elm UI. Elm UI essentially, Richard Feldman gives a talk on it, where he uses the analogy of it being treating CSS and HTML as bytecode for your views. I think that's a really apt way to put it. If you break down this idea of CSS -- Cascading Style Sheets, it removes the cascading part of CSS and it removes the sheets part of CSS. What you're left with is a way of expressing style and it's a way of expressing style that is able to part ways with all of the baggage of the entire history of backwards compatible decisions that CSS has ever made. If you want to vertically aligned something, then you just say, "Align vertically," you know, center vertically. If you want to center something horizontally, you say center X. It creates a high level language for expressing views. My experience with Elm UI, this may not be the right choice for every team but I love it. I use it on all of the projects that I maintain personally. I love using it because it gives you that same sense of invincibility refactoring that you get with Elm, which is remarkable that you could have that feeling with managing views. CHARLES: It's definitely something that feels like a dark art and it can't be called science. It's an art. It's a science for some people but it's historically been a dark art and something fiddly to work with. In terms of being able to make the experiment with Elm, when we talked a little bit about why you might want to experiment with it in the first place, what the business case is, I guess my next question is or a question that immediately comes to mind is supposing that we have decided to experiment with this, how do you mitigate that experiment? We talked about lowering the cost, having a way to turn away from it, having a way to make it inexpensive. For example, one of the things that I think of when evaluating a new technology is how well can I use it with old technologies. I have a lot about best practices in my tool bag. We all do. We got our all favorite libraries and pathways that are just familiar to us. One of the things that I've noticed is when adopting a new technology, one of the things that makes it easy to experiment with is how well it works with the existing technologies. I know that, we talked about Elm UI, kind of rethinking style in CSS and your views and Elm itself as a completely different language within JavaScript, that can be both liberating but it can also be limiting in the sense that I can't reach back for my existing tool if no tool exists in this new space. The kind of experience that I've had where this is really worked is systems like JRuby or Clojure, where there's a very clear pathway to be able to use Java libraries from those environments, so you always have kind of an escape hatch. What's that like in Elm? DILLON: This is a really interesting conversation because it highlights, in some ways some of the most defining features of Elm. In terms of how do you kind of pull Elm into an existing application, there are a lot of different techniques for that. It's pretty straightforward to create a little Elm app. We usually don't call them components for reasons that we can get into if we want to but that's a whole can of worms. But if you've got a little Elm application that you want to use to render a widget on your page, then it's as simple as just calling Elm.yourmodule.init and rendering it onto the page there. That's quite straightforward and if you want to interface with your existing code there are several ways to do that. There's something called port in Elm, which is how you kind of communicate by sending these messages and data back and forth between your Elm app and JavaScript. Now, this is one of the decisions, I think that defines Elm as the language and the reason this is important is because Elm decided not to make the choice that a lot of other compile to JS languages do. For example, if you look at ReasonML or PureScript or a more extreme example, TypeScript. TypeScript is a superset of JavaScript, so it's trying to allow you to gradually introduce this to get some incremental improvements for your JavaScript code, so it's extremely easy to experiment with it, which we've talked about the importance of experimentation. Now, the challenge with this technique, the tradeoff here is it's great, that it then becomes very easy to transition into it and that's an excellent strategy for the goals of TypeScript. Elm has a different set of goals, so the things that elm is focused on giving you is a truly type-safe experience. When you're working with Elm, if your Elm code says that this data is a float, then it is a float. Either, it is a float or that code is not being run and so, that's very different than the experience in TypeScript where you have these escape hatches. This is an inevitable choice for any compiled to JS language. Are you going to have escape hatches or not? Elm is really the only language out there, I think that chooses not to have escape hatches and that is actually the thing that that I love about the language because that's the only way you can truly have guarantees, rather than, "Yeah, I'm pretty sure that these type guarantees hold." DAVID: Yeah, wishes and dreams. DILLON: Yeah. CHARLES: What does it mean to have no escape hatches? because you talked about ports. Does it mean like it's impossible to use an external JavaScript library? DILLON: That's an excellent question. You absolutely can use JavaScript libraries. It means that it's being explicit and upfront about the fact that there's uncertainty in these areas. That's what it comes down to. Take for example dealing with JSON. In a JavaScript application, what we get when we're dealing with JSON is you make a request up to the server, you have some callback that passes in the data you get back and then you start pulling bits and pieces off of it and you say 'response.users subzero.firstname' and you hope that none of those things are null, none of those types are different than what you expected. In a way, it's kind of letting you pretend that you have certainty there when in fact, you don't and with Elm, the approach is quite different. You have to explicitly say, "I expect my response to have this shape. I expect it to be a list of things, which have a first name and last name which are strings," and then Elm says, "Okay, great. I'm going to check your assumptions," and if you're right, then here you go and you're in a well typed-space where you know exactly what the types are and if you're wrong, then that's just another type of data, so it's just a case statement where you say, "If my assumptions were correct, then do something and if my assumptions were incorrect, then you decide what to do from there." CHARLES: Right. For me, it sounds like there is some way because ultimately, I'm going to be getting unstructured but I'm going to be getting JSON back from the server and maybe, I have some library that's going to be doing that for me and enhancing it and adding value to that JSON in some way. But then at some point, I can present it to Elm but what you just saying is I need to be complete in making sure that I handle each case. I need to do or handle the case. Explicit about saying if the assumptions that Elm wants to make, turn out to not be true, Elm is going to make me handle the case where those assumptions were not true. DILLON: Exactly. I think that TypeScript of any type is the perfect illustration of the difference. TypeScript of any type is sort of allowing you to say, "Don't type check this. Trust me here," and Elm's approach is more kind of just be explicit about what you want me to do if your assumptions are incorrect. It doesn't let you kind of come in and say, "No, I know I'm going to be right here." CHARLES: Right but there is a way to pass data structures back and forth. DILLON: There absolutely is and actually, there's a technique that's starting to gain some traction now, which I'm really excited about, which is rather than using this sort of JavaScript interrupt technique we talked about, which is again, it's very much like communicating with a server where you're kind of sending messages and getting data back -- getting these messages with data back. But there's an alternative to that which is using web components. Actually, there's quite good support for assuming that you don't need to be compatible with Internet Explorer. Basically in a nutshell, if you can wrap a sort of declarative web component around anything, it could be a Google Maps API, it could be a syntax highlighting JavaScript library, something that you don't have an Elm library for but you want to use this JavaScript library, it's actually quite a nice experience. You just render that custom element using your Elm code just as you would any other HTML in Elm. CHARLES: Yeah I like that, so the HTML becomes the canvas or composition with other JavaScript and the semantics are very well-defined and that interface is actually pretty thin. DILLON: Exactly and the key again is that you wanted to find a declarative interface, rather than an imperative one where you're kind of just doing a series of statements where you say, "Do this and then set this value and then call this and then set this call back." Instead, you're saying, "Render this Google Maps custom element," which is centered around these coordinates and has this zoom level on. You declaratively give it the bit of information that it needs to render a particular view. CHARLES: Okay. Then I guess the final question that I have around this area is about being able to integrate existing tools and functions inside of an Elm application. Because it sounds like you could theoretically develop large parts of your application, is there a way that you can actually have other areas of your application that are not currently invested in Elm still benefit from it, in the sense for kind of need of JavaScript APIs that Elm can make available. DILLON: Right, so you're kind of talking about the reverse of that Elm reaching out to JavaScript. You're asking about, can JavaScript reach out to Elm and benefit from some of its ecosystem? CHARLES: Exactly. I say that is that another potential vector for experimentation. DILLON: It's a really interesting thought. I haven't given it too much thought, to be honest but I actually have heard it come up before and my gut feeling is that it's probably more fruitful to explore the inverse, reaching out to JavaScript from Elm and the reason is kind of the main appeal of Elm is that when you're operating within Elm, you have this sense that if it compiles, it works. Because again, this central decision to not allow escape hatches is what allows you to have that sort of robustness, so you have this feeling of bullet proof refactorings and adding new features seamlessly where you change your data modeling to say, "Here's this other case that can be represented," and then suddenly, the Elm compiler says, "Tell me what to do here, tell me what to do here and tell me what to do there," and you do it and your app is working. That's the real appeal of Elm, I think and you don't really get much of that by just calling out to an Elm library from within JavaScript. That's my gut feeling on it. CHARLES: Okay, that's fair enough. On the subject of interrupt and using tools like JSON, you actually maintain a GraphQL library for Elm. You probably have a lot of experience on this. Maybe we can talk about that as a concrete case that highlights the examples. DILLON: Yeah. I think to me this is one of the things that really highlights the power of Elm, to give you a really amazing refactoring and kind of feature creating experience. A lot of Elm libraries are prefaced by the author name, so it's still DillonKearns/ElmGraphQL. I spoke about it this year at ElmConf. In a nutshell, what it does is it actually generates code based on your GraphQL schema. For anyone who doesn't know, GraphQL is just kind of a language for expressing the shape of your API and what types of data can return. What DillonKearns on GraphQL does is it looks at your GraphQL schema and it generates an API that allows you to query that API. using this library, you can actually guarantee that you're making a valid query to your server. Again, you get this bulletproof experience of refactoring in Elm where you can do something like make a change in your API and recompile your Elm code and see whether you've made a backwards incompatible change. All of this effort of doing sort of this JSON decoding I was talking about earlier where you kind of have to explicitly say, "These are my assumptions about the shape of the JSON that I'm getting back." When you're using this library, you no longer need to make any assumptions because you're able to rely on this sort of schema of your API and so you know when you're requesting this data, you don't have to run it, see if it works and then tweak it and run it again -- this sort of cycle of checking your assumptions at runtime. It moves those assumptions that you're making from runtime to compile time and it can tell you when you compile your application, it can say, "Actually, this data you're requesting, it doesn't exist," or, "It's actually called this," or, "This is actually the type of the data." CHARLES: Right. I love that. How do you do that? Because it seems like you've got a little bit of a chicken and the egg problem because the schema is defined outside of Elm, so you have to be able to parse and understand the schema in order to generate the Elm types to be able to compile Elm code against them. Maybe I'm not -- DILLON: That's exactly right. That's exactly what it does. Now, the nice thing is that GraphQL is really designed for these types of use cases. It supports them in a first class way. If you have a GraphQL API, that means you have built into it whether you know about it or not, a way to introspect the schema. All of the queries for kind of interrogating that GraphQL server and asking what types of data does this return, what are all your queries that I can run, it's built into it by the framework, so that comes for free. Getting up and running with this package I built is as simple as running a little npm CLI, pointing it to either your URL for your server or the JSON form of your schema, if you prefer and then, it generates the code for you. CHARLES: Wow, that sounds fantastic. This is the exact kind of thing that feels like it would be cool if I could just start using this library to manage the GraphQL of my application but I'm consuming that GraphQL from other JavaScript but it's the Elm code that's managing it. Do you see what I mean? DILLON: I hadn't considered that. I guess you could. You're right. Maybe I'm so smitten with Elm that it's hard to see an in-between but I guess, you could get some benefits from that approach. CHARLES: Right and as an experiment of course. DILLON: There you go. There you go. CHARLES: All right. With that, I think we'll wrap it up. Thank you so much, Dillon for coming on and talking with us on the podcast. DILLON: My pleasure. I really enjoyed the conversation. CHARLES: I actually got so many great tidbits from so many different areas of software development in Elm but also, just in kind of other things that I'm interested in trying. It was a really great conversation. DILLON: I had a lot of fun and I love discussing these things. For any listeners who are interested in this stuff, feel free to reach out to me on the Elm Slack or on Twitter. I'm at @DillonTKearns. I'm also offering a free intro Elm talk for any companies that are kind of entertaining the idea of doing an experiment with Elm. If you go to IncrementalElm.com/Intro, you can find out about some of the talks that I'm offering. CHARLES: All right. Well, thank you very much and we, as always are the Frontside. We build software that you can stake your future on and you can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io on email. Please send us any questions you might have, any topics that you'd like to hear about and we look forward to hearing from you and we will see you next week.

Cascading Style Sheets let you manage how your HTML looks so you can keep your HTML focused on the content.

Cascading Style Sheets let you manage how your HTML looks so you can keep your HTML focused on the content.

02:59 - Rob Wormald Introduction Twitter GitHub 03:46 - Stephen Fluin Introduction Twitter GitHub Blog 04:28 - Improvements Coming for Routing in Angular 08:22 - Syntax 11:10 - Preloading Data 13:59 - Brian Ford’s Router => The New Router Lifecycle Hooks canActivate canDeactivate 17:23 - Does the new router do these things? Can I click on a link and tell it to go to a route? Can I pass parameters; multiple parameters? Can I add multiple routes to multiple different regions on the page? If I’m a child component, can I reach up and learn anything about my parent, and if so, what can I do? Will, with this router, do I have the option of Lazy loading the routes or loading them all up front? Can I route to two different states on the same page? 23:28 - Auxiliary Route 24:51 - Offline Compilation CSS (Cascading Style Sheets) 29:38 - Bundling; Development Experience 32:46 - Relative Pass 41:25 - Treeshaking 43:21 - What’s left before Angular goes live?   Picks rollup.js (Rob) Google Play’s Family Plan (Jules) Plunker (Stephen) Ford and Chevrolet (John) Adobe Lightroom (John) X-Men Apocalypse (Joe) P.I. (Joe)

02:59 - Rob Wormald Introduction Twitter GitHub 03:46 - Stephen Fluin Introduction Twitter GitHub Blog 04:28 - Improvements Coming for Routing in Angular 08:22 - Syntax 11:10 - Preloading Data 13:59 - Brian Ford’s Router => The New Router Lifecycle Hooks canActivate canDeactivate 17:23 - Does the new router do these things? Can I click on a link and tell it to go to a route? Can I pass parameters; multiple parameters? Can I add multiple routes to multiple different regions on the page? If I’m a child component, can I reach up and learn anything about my parent, and if so, what can I do? Will, with this router, do I have the option of Lazy loading the routes or loading them all up front? Can I route to two different states on the same page? 23:28 - Auxiliary Route 24:51 - Offline Compilation CSS (Cascading Style Sheets) 29:38 - Bundling; Development Experience 32:46 - Relative Pass 41:25 - Treeshaking 43:21 - What’s left before Angular goes live?   Picks rollup.js (Rob) Google Play’s Family Plan (Jules) Plunker (Stephen) Ford and Chevrolet (John) Adobe Lightroom (John) X-Men Apocalypse (Joe) P.I. (Joe)

02:59 - Rob Wormald Introduction Twitter GitHub 03:46 - Stephen Fluin Introduction Twitter GitHub Blog 04:28 - Improvements Coming for Routing in Angular 08:22 - Syntax 11:10 - Preloading Data 13:59 - Brian Ford’s Router => The New Router Lifecycle Hooks canActivate canDeactivate 17:23 - Does the new router do these things? Can I click on a link and tell it to go to a route? Can I pass parameters; multiple parameters? Can I add multiple routes to multiple different regions on the page? If I’m a child component, can I reach up and learn anything about my parent, and if so, what can I do? Will, with this router, do I have the option of Lazy loading the routes or loading them all up front? Can I route to two different states on the same page? 23:28 - Auxiliary Route 24:51 - Offline Compilation CSS (Cascading Style Sheets) 29:38 - Bundling; Development Experience 32:46 - Relative Pass 41:25 - Treeshaking 43:21 - What’s left before Angular goes live?   Picks rollup.js (Rob) Google Play’s Family Plan (Jules) Plunker (Stephen) Ford and Chevrolet (John) Adobe Lightroom (John) X-Men Apocalypse (Joe) P.I. (Joe)