Algorithms + Data Structures = Programs - Episode 26: Sean Parent on Slides Decks, UI & More

Episode Date: May 21, 2021

In this episode, Conor and Bryce talk to Sean Parent about a plethora of topics including slides, UI and more.About the Guest:Sean Parent is a principal scientist and software architect for Adobe Photoshop. Sean has been at Adobe since 1993 when he joined as a senior engineer working on Photoshop and later managed Adobe’s Software Technology Lab. In 2009 Sean spent a year at Google working on Chrome OS before returning to Adobe. From 1988 through 1993 Sean worked at Apple, where he was part of the system software team that developed the technologies allowing Apple’s successful transition to PowerPC.Date Recorded: 2021-05-19Date Released: 2021-05-21Sean Parents Paper: P2345 Relaxing Requirements of Moved-From ObjectsGoingNative 2013 C++ Seasoning - Sean ParentSean McQuillan - Launching Into CoroutinesReveal JSJupiter Notebooksxeus-cling Jupiter kernel for C++All PowerPoint ShortcutTools 3.0 Keyboard ShortcutsGreat Impractical Ideas in Computer Science: PowerPoint ProgrammingCppCon 2019: Sean Parent “Better Code: Relationships”ASL Eve Layout EngineASL I/O ManipulatorsC++20 std::formatIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

The hat is back! I'm so excited that the hat is back. I know, my hair is amazing. So Connor usually wears a hat, like when, recorded on May 19th, 2021. My name is Connor, and today with my co-host, Bryce, we interview Sean Parent for the second time. This is part one of our two-part interview with him, where we talk about slide decks, UI, and so much more. Have you fixed your audio setup so that you're no longer recording in a closet? No, man. You haven't listened to the last episode, but my audio has never been crispier. It is so crispy. So you're in the closet, aren't you?

Yeah. We're doing a little experiment today because I have acquired two chairs. So now I have three chairs. And the chairs that I have, I got, I mentioned before, I got from my sister. And this one is not like a desk chair though, so it doesn't have any cushion

or fabric on it. It's just like a lightweight, I don't know, sort of party chair. And we'll see. Maybe I'll have to revert back to the office chair if my audio is not as crispy anymore because fabric equals less echo. I'm like, I'm on my way to becoming an audiophile. I was about to say, you're such an audiophile i was about to say you're such an audiophile nerd except it's so sad because like i'm where i have these like a hundred dollar sports uh bows like uh running headphones that i'm using wait was that was that supposed to be that those headphones are not impressive enough no yeah like an audiophile would have some $700, you know, with some special cables and stuff that I don't know about.

But you realize that it's pretty privileged that you just said, oh, yeah, I only have these $100 Bose headphones. I don't have the $700 headphones. Yeah, my bad. I should check my privilege. But if you can if you can see like the little plastic casing around the wires is all like torn up and I'm about to electrocute myself one of these days. Audience, these these headphones are not in good shape. I'm actually I'm I'm very excited because since we last talked, Sean has submitted his committee paper on moved from objects, which we just scheduled last week. Yeah, yeah. Scheduled for out in August, which seems like a long time.

But yes, unfortunately, unfortunately, with with how our schedule during the pandemic is, August is the first time chance that we'll get to look at it. But I'm excited for it. It's it's it's probably been a few years since've, you've been in a C++ committee meeting or. Yeah, it's, it's been quite a while. This came about because, uh, John Lakos approached me at ACCU virtually and he's working on his new book. And he said that he knew that I had an annoyance with move semantics and wanted me to write something up on it. So I wrote about three pages for his book. And then he suggested, he said, you know, this would be a better three pages if it could reference a standards proposal to fix it. So I wrote the standards proposal to fix it. See, you got nerd sniped. That is a pro

Lakos move to get somebody to write a paper. Yeah. Lakos is a notorious manipulator. I assume that both of you have seen John Lakos give a talk. I love how that man gives a talk. And I, in particular, I really appreciate how he makes a slide deck. Because he does it the same way that I do, where I don't put any transitions into my slides, but instead I'll have multiple slides that, if I wanted to have a slide with transition, I'll have a few different slides,

each one that adds another element to the last slide. And I don't really know why i do that i guess it's just like uh i feel like it gives me a little bit more control in it and then it exports to pdf better um uh but uh so so as a result of this john lakos will come to give an hour-long talk and he'll be like oh yeah i've got I've got 800 slides. Yeah. Yeah. Every time I'm working on a slide deck, I have to resist the urge of writing my own slide deck engine because I can't find a tool that does what I want. Yeah, I think I recall I asked you once in your C++ seasoning talk how you did the really nice, like, sliding code up the screen. And I was expecting, oh, it's going to be something super fancy,

but you basically did it like the classic, I think, like just big images, and then you, like, move it up the screen, and then it looks like it's sliding. But it's done so, like, flawlessly that I thought for sure you had some, like, custom Adobe, like, unreleased keynote or PowerPoint. No, no, that was done painfully and manually in keynote. So yeah, yeah. I would, there's not many things

that I would like really believe and invest in, but if Sean Parent wanted to make a slide engine, that I would get on board with. It's funny how many times there's been at least like a handful of slide decks or presentations that I've seen. I can remember one too. Sean M. I'm going to forget his last name.

He works at Google. And he did a talk on coroutines and Kotlin. And he did this like little history of coroutines. And it was like zoom in, zoom out, all this just amazing. And I thought he must be using Prezi, must be using something. And then I went and asked him after. And he was was like no i just a bunch of images it's very you know very painful and i'm like why we got all these beautiful presentations and we haven't figured out how to make it uh easy for slide deck people you know i i used reveal so i usually use

powerpoint for my slides one time for my 2017 uh talk that was like an intro, it was called C++ 17 Features. It was an introduction to like, you know, every C++ 17 Features. For that talk, I decided I'm going to try the new cool thing and try using reveal.js, which is like a slide framework where you write your slides in like markdown and you know you put them in a github repo and they get compiled to you know html and javascript um it's what all the cool kids use and i tried it and the you know the main reason that i wanted to use it was testability of my sample code you know i wanted to be able to write the code in a way where I could compile like all my example code locally and then have that

be imported into the slides so that I could unit test all my example code in the slides because every talk that I'd give some person would afterwards come up to me and say, aha you had a typo on this line. You had a typo on that line. I wanted to avoid that. And so I did the presentation and it was like, I'm not saying it was a bad experience, but it was just like, not for me. Because the problem was that when I needed, when I wanted to go and like change where something was on the screen. You know, I couldn't just go do that. I needed to go into the file and like edit something and like edit a location. Whereas what I wanted to do was like visually move a thing.

And at that point in my career, I was like, you know, the person who was like, I just want a Vim interface to everything. Like I want to do everything in the command line. You know, GUIs are for suckers. I don't want to use a GUI for anything. And that, and like, I, you know, of course, like I'm going to use Linux for everything. I'm just going to, my interface to the world is a Linux command line interface. And that was the moment when I like first came to really appreciate the power of a good graphical interface because like for making a slide I wanted to be able to

like visually see it and like move it around and then be like yeah that looks that looks that looks pretty good it looks pretty good and like after that I have increasingly I've increasingly like spent more of my time thinking about like like, you know, is this a task that I want the, sort of, the efficiency gains that I might get from something that's purely textual, or do I want, you know, I want a graphical interface to this thing, because it's something that I really need to visualize and, like, visually see. Yeah, when I'm teaching classes or just developing a new slide deck, I use Jupyter Notebook, which is usually a data science thing and associated with Python.

But it's got support through something called Zeus Cling to let you put interpreted C++ 17 embedded directly in your notebook and it's executable and and the notebook can output to reveal.js and so I can build up my whole slide deck with all of my code and all of my code is executable and you can see the results directly on the slides and I can go change the code and and edit it and and figure out the right order to structure things so that, you know, so as the user's going through the slides, they see all the pieces that come together. But controlling the output of it is painful enough that, you know, it's fine if I'm teaching a course

and it's just like the equivalent of a whiteboard. But if I'm going to do a keynote presentation or something, then that's my draft. And then I'll sit down and keynote and make it pretty. I do want to take this opportunity to plug a PowerPoint plug-in that I recently purchased and have used, which has been been transformative which is it's called PowerPoint Shortcut Tools and it is super awesome. It makes it so much quicker for me to build my

PowerPoint decks because it's got a whole bunch of very useful key bindings and macros. I've got a collection of scripts for Keynote that I've written over the years that probably do some of the equivalent things. It's like, you hit one button and... That's awesome.

You would. I've thought about learning how to. I learned once, because Excel macros are a big thing, and I got into that when I was younger. And then I'd heard about Access. That's Microsoft Access, like the database, not any other word that you might have confused what I just said about access that's Microsoft access like the database not any other word that you might have confused what I just said with it's a terrible name there's access VBA like macro programming but I looked into to see like I think the most useful at this point of my life would be like a PowerPoint like little scripting language but when I looked into that I

just found a YouTube video of someone building like a Turing machine and PowerPoint and doing some crazy things, which which I can link that in the show notes if anyone's ever wondering, because this is probably the number one question I get asked is how do I do my little code animations? It's a transition called morph. I think keynote has the same thing called magic or something like that. And yeah, you just you have to change the mode to words instead of objects. And then it figures everything out. It's an amazing algorithm. And I'm, I'm very sad that I tried to mimic that stuff, uh, in pre Microsoft PowerPoint 2019, cause it was just so much work, but. No, I, I got one more thought on this,

but then I got one more thought on this and then I got a good transition. Um, do you know what we're transitioning to though? No, I know what I'm transitioning to. I want to try. The reason that I invested in, the reason I bought a copy of shortcut tools was for copy object position, which is a really useful, you know, key binding to have like, hey, this thing's at this position on this slide. On this other slide, I want this thing at the same, I want a different object at the same position. And then, of course, like key bindings to align various different things. I drive my colleagues crazy because I'll look at their slide decks and I'll be like, that's not aligned, that's not aligned.

Like, send me your PowerPoint. I'm going to go through and align all your things for you. But speaking, here's the transition. Wait for it. It's really, speaking of user transitions, I don't work on graphic user interfaces. And like, really, I solely work on like libraries in the back end. I don't really work in anything that has like, quote, civilian users. And so I never really thought much about user interface or graphical interface until I saw one of Sean Parent's more recent talks,

which I think was at CppCon in 2018 or 2019 on user interfaces. It was one of the better code talks. And for somebody who doesn't think about user interface, it made me care about user interface. I really loved that talk. Well, thank you. So I'm trying to think of,

because I've done a couple of talks that include user interface bits. It was the one where you had the slides about the user interface of a bathroom in a hotel in Germany that you stayed at from meeting C++. Yes, yes, okay. I think that's my relationships talk. Right. The relationships talk. Yes. Yes. That's what it was. Yeah. Yeah. Yeah. It was really interesting to see how you think about that because it's a field that I've never even thought about before. Yeah. Yeah. And there's a section in it it which is near the bathroom section, which is going through possible user interfaces for just an implies relationship between two Booleans.

You know, A implies B. And all the different ways that that could be represented and all the tradeoffs in making that representation. And all the ways to get it wrong. And I send that little snippet out frequently when I'm working with designers because it's this problem area where every time a UI designer hits an implies relationship, and they're quite common in user interfaces, they basically start from a blank sheet and they're like, okay, so I've got this relationship where if I click on this then that needs to be true and they'll start with, okay, so

how should I represent that and what are the behaviors involved and I have these frequent arguments where I think the UI industry as an industry should really work on rule sets on like, okay, if we have an implies relationship under these circumstances, we're going to, to build it this way, under a different set of circumstances, maybe we'll take a different approach, but build up what the rule set is and document it well and establish standards for things like that. At Adobe, do you have, is there like a set of design principles for something like Photoshop for the UI for things like this? Yeah, we have a design team and a set of design principles that go around that. And, you know, a team of designers

that are trying to bring all of the Adobe applications to be more consistent, which is always a problem because Adobe grows largely through acquisition. So, you know, as soon as you think you're there, you've kind of sucked in a couple more products and you've got things to normalize. So we do have a team that works on that. My criticism of the team would be that they tend to be a little myopic,

which is they tend to build the rules around individual features as opposed to building what we would call generic rules. Right, right, right. What things have that shape and build the rules around things that have that shape. So when you encounter a new problem, you can figure out, well, what are the attributes of this problem

and what rules would apply to this and come up with a good design without invoking a designer and having them draw a bunch of pictures. That reminds me of a conversation that I had with, that I either had with Tony, or it was on the podcast with Tony at C++ Now, where Tony was talking about, he maintains this set of design principles at his company. And whenever he does a code review, if he sees something that he doesn't like, and there's not a design rule that covers it,

he goes and thinks up and writes a design rule for it and puts it into the guidelines. Yeah. Years ago, I wrote a layout engine. It's open sourced. It's known as EVE. It's part of Adobe Source Libraries. And it's a layout engine for UI. And it gets used heavily at Adobe.

In fact, almost all of Photoshop is laid out with Eve. And Eve has its own kind of baked-in rule sets for doing layout. And the rule sets came about because at the time I was working with a Photoshop designer, and I would, you know, this was years and years and years ago, so I would literally you know, this was years and years and years ago, so I would literally do this on paper. I would print out different variants of a UI and go to her and ask her which one she liked better. And she'd point at one and go, you know, this is the best one. And then I'd be like, why? Why do you say that? And, you know, the conversation would always start

with, well, because it looks better. And it's like, not good enough, right? Right. And, you know, the conversation would always start with, well, because it looks better. And it's like, not good enough. Right? Right. And eventually you would uncover, you know, she had a very strong design sense. And she had internalized a bunch of design rules. And so you would just have to, you know, I would have to pull those out of her. It's like, well, it looks better because this over here is aligning with that over there. Right?

And so then I would go and print a whole bunch of things where things aligned in that way. And she would go through and mark them up and be like, yeah, but this one's wrong. And I'd be like, okay okay why is that one wrong well because in this case you know this should really be aligning with this other thing because that's a stronger a stronger visual aspect and so so it was you know months of kind of working with her to to dig out her her design sense and encapsulate it into a set of rules and build that into the code i think it's interesting that you said like alignment there like three or four times because a lot of times people ask like oh you know what should i do to improve slide decks and stuff and

like it really is just a set of like three or four simple rules and like two of the main things which i think bryce you mentioned came in your plug-in set are like the alignment you know top bottom left right and then also like the vertical and horizontal spacing like small things like that if you have i think we've even talked about this the last time you were on where you have like you know five bullet points and one of the bullet points is got like an extra half line spacing in it than the other ones like that's not symmetric i think our eyes are drawn to like symmetry because it's it's pattern recognition it's easier for our brains to oh this is all sort of in the same thing when something is off uh at least for me it doesn't look as nice and and a lot of the times it's just like lining things up nicely which is a small

thing but it can make a big difference well and, and also how you use space. If there's a dead space on your slide, if you're using all of your vertical space, but you've got huge amounts of dead space horizontally, just big blank regions, it just pains my heart. It pains my soul. And alignment's a difficult thing too, because it's what are the strong edges that your eye is attracted to and kind of understanding that. And in the case of text, you really want the baselines of your text to align. And when building UIs, that can get very complicated because you've got a button next to a pop-up or something, and those things have different heights. And as a developer frequently using an OS toolkit, you don't have control over where the OS is putting the text within those rectangles, but you really want to align the baselines between those two rectangles.

Well, and you have to think about how it's going to align when it's localized, right? Yes, yes. And different languages have different rules. So things like, you know, Korean is, you know, centered aligned as opposed to baseline aligned. So, yeah, things like that are challenging when you're worried about building UI. Eve does some pretty nutty things to kind of make some of that stuff correct. it handles bizarre cases like a mix of left to right and right to right and right to left languages within the same UI and handling alignment across those two cases, which it turns out in some parts of the world is fairly common. Yeah. One thing that I probably spend

more time thinking about than I should is if I'm making a spreadsheet, how am I going to align the columns? Because if it's something like, you know, I think the left align for, you know, the rows of a table is probably like the most natural thing to me, just stylistically. I sort of think it's similar with like Sean said, like I don't necessarily have a good like reason for it, but it's just sort of like, you know, a gut, you know, a gut thing. It's sort of like natural language. Like might know that a way of phrasing something in English is not grammatically correct, but you can't name the particular rule for it. But if you left align numbers like currency, then it's harder to see the difference in magnitude between two different rows. And this is, I think, why Excel defaults to left alignment for text, but then right alignment for numbers. But then if you have some of your columns that are right aligned because they're numbers,

and then others are text, and they're left like, should you right align all of them? What about the headers? Should those be centered? Should those be, you know, left aligned or right aligned? It's like I spend more time thinking about these things than I probably should. For numbers, that's a case where we borrowed numbers from Arabic. So they're Arabic numerals and hence they're right to left. Yeah. Excel is...

I think they have a format for currency where it aligns the currency symbol and then right aligns the two decimal places and the decimal and the number. And so it figures out the maximum width of the integral part of your money amount. And that's my favorite, because that to me has the most symmetry, like all the decimals are lined up, all the money symbols of dollar sign or pound sign are all lined up. And then the only thing that's off is like when you have a, you know, $10 amount versus $100 amount, like you're going to have some empty space there. But like, for me, that's you can even like just sort of blur, squint your eyes and blur them. And like,

you can see what the largest roughly what the largest amount is just by seeing which one is kicked out furthest to the left from the right this isn't even like a gooey problem you know as anybody who's ever tried to deal with uh padding um in uh with printf knows this is like not an easy not an easy thing to to clearly express it's one of the reasons why i'm so excited about std format um being in the c++ standard library because uh it's just such a better solution than the prior ones for doing something like i want i want this to be like padded in a certain way so that these things line up when I print them out in a for loop. Yeah, yeah. I like std format. It's still one of the things we had in ASL was a library for

structured serialization. And that's one of the things that I think is still missing from C++. And at some point, I'd love to continue that work. But the idea with structured serialization is you format things based off the shape of the object. And so you have, is this thing a dictionary? Is it an array? Is it just an atom type, like just a number or just a string? And then once you have the structural information about what it is that you're printing, and that's all you need to describe to print something, then you can have a bunch of different back-end formatters. So you can say, well, output this structure as XML, output it as JSON,

output it as PDF as its own serialization format, output it as PDF. And so inside of the ASL, we have this concept of structured serialization. And so to use it, you just have to basically describe the shape of your objects, and then you can output them into any one of these formats. I actually do think that this is something that the C++ standard library will do eventually. And I think it's probably a good idea. And I think a design similar to what you just described will make a lot of sense too because while I'm not a huge fan of the idea of putting, say, a JSON or an XML library into standard C++, having some way of taking a representation of a C++ object and getting out JSON or XML

would be really nice. And, you know, especially as we get, once we get reflection in the language, we'll be able to really build an excellent serialization facilities too. And so I think that's something, you know, in my CPAS was now keynote, I highlighted four priorities for the standard library. It was asynchrony and parallelism, IO, text processing, and metaprogramming and reflection. And I mean, that serialization really hits the IO and the metaprogramming reflection. And that serialization really hits the I.O. and the metaprogramming reflection. And I think it's going to be important in the future. I hope the Standards Committee takes an approach of being agnostic

about the format of serialization and focusing on the structural aspects because if you look at, say, Objective-C has serialization, but it's in Apple's own format, proprietary format, and so the ones you move to say, well, I want to be able to serialize in JSON or XML, now you're on your own. And so it would be nice if C++ went the route of kind of being agnostic and being like, no, no, no, we're going to have an API that lets you plug in the actual formatter,

and we're just going to have a standard way to describe the structural information. Yeah. And that's a very C++-y way to do things. Like I like to say that the thing that makes C++ C++ is this idea of universality, that C++ doesn't in C++, there usually is no one right answer. The right answer is to support whatever the right solution is for each individual domain. Thanks for listening. Tune in next week for an epic part two. Have a great day.