Today, I sit down and talk with David Norris, Solution Engineer for Salesforce, about web component development. We specifically discuss his experiences in building a complex and highly visible lightning web component in the form of a timeline that renders a visualization for related data like events, tasks, and opportunities. In this episode, we break down the component creation process, from conceptualization to release.

Show Highlights:

  • David’s conceptualization of component development 
  • Going from the ideation phase into the actual design phase
  • David’s philosophy on user-centered design: “If you have access to people that do user-centered design for a living, you should use them.”
  • By designing on paper first, you can iterate much faster.
  • Some of the tools David found useful during the design and mock-up phases
  • His experience incorporating a third-party library into a web component
  • The testing and replication process

Resources:

Episode Transcript

00:07

David: Absolutely be vulnerable, put it out there. And you know learn from others experiences people have given me some great feedback.  They probably facepalm every time they using acronyms I don’t understand. But that’s part of the learning process.  For me. I go in Google afterwards.

00:22

Josh: That is David Norris, a solution engineer for Salesforce based in Australia. I’m Josh Birk, a developer evangelist for Salesforce. And here on the Salesforce Developer Podcast, you’ll hear stories and insights from developers for developers. Today, we sit down with David to talk about his experiences in building a complex and highly visible lightning web component in the form of a timeline that renders a visualization for related data like events, tasks and opportunities. Over the next 30 minutes, we will break down the process David used to create the component starting with conceptualization.

00:53

David: When I started looking into developing a component I realized that the first thing I needed to be able to articulate really well is What is this component going to be able to do? Why is it better than what a user might be used to using now? And why should people care? So it sounds fairly easy and straightforward and maybe common sense. But I actually found that quite difficult to do. So that’s where I started articulating things like being able to identify clusters of activity being important. Being able to scroll back more than 18 months worth of history was important. And I started to be able to decide on these pain points because I did some research. So if you work for an ISV partner, or you work for a big company like Salesforce in the engineering team, you probably run things like a customer advisory boards and you send customer surveys to solicit a lot of research from customers about what they are wanting. But for me, I didn’t have access to those resources. So chatting to colleagues, they told me that there are two important things you should do. You should crowdsource ideas from the idea exchange. Because they are ranked and rated for you, they have great comments. So by doing that, I knew that it was important to be able to go back more than 18 months worth of history.

02:11

And I also reviewed existing solutions. So there is the app exchange. So go and have a look, there was a universal timeline on the app exchange, I looked at industry solutions, like the health cloud timeline. So these are ready made things you can go and research at a very low cost. But they have a very high value, because you can work out what they do well, and what they don’t do so well. So that’s really where I started.

02:36

And when you start going from that ideation phase into more of the actual design phase, so you’ve gotten some of your features listed. Now you’re moving into what it’s going to start looking like. I think some developers are like, Oh, how I design my component as I you know, pull up Visual Studio code, I just started coding, what are the steps that somebody should consider taking moving from that ideation phase into more But a design like phase before they actually start coding.

03:02

So for me, it was an opportunity to think a bit differently to Visual force. So I was very used to being constrained when I developed in visual force, because fundamentally, what I could do with the visual force where it could appear on the page was limited. So sort of restricted some of my options. So I tended to focus on what I wanted, not necessarily what the end user was developing for wanted. In the new world of the lightning desktop, where there are now components I can drag onto a page, it really required me to think differently. And the whole concept of user centered design sort of started researching it a little bit on being able to iterate and learn and constantly improve. I suddenly realized that even the concept of the user was different in lightning web components for me because I was no longer just developing for an end user. I was also developing for administrators who are going to drag it onto a page, and I was also developing for developers who might be reusing my component themselves, so not just user but users correct yet. So now I have flexibility and flexibility gives me a new mindset to make sure that when I design a component, I’m factoring in those three personas if you like,

04:24

Josh: gotcha. I mean, flexibility is a great thing. But it’s kind of like that, you know, power and responsibility line too.

04:30

David: Yeah, exactly. Because when you drag a component, even if it’s an out of the box component onto a page, how cool is it that at design time, an administrator, who isn’t necessarily writing code can change properties. So they can change the title, they might be able to change colors, they can decide, even if it’s shown based on certain field attributes. That’s a very powerful construct when you’re developing applications, but completely useless if your customers component you’re developing doesn’t follow those same principles, right. And back at the Visualforce days, the developer just sort of gave them whatever was going to be delivered pretty much the requirement was the idea, and you delivered it. And I think we had field sets to make it, you know, configurable at design time, but really even making the Visualforce page dynamically, that height dynamic, was fairly difficult if you wanted to present a record page. So it’s, it’s exciting, but it requires you to start thinking about what properties of your component should own a straight up, be able to change where on the page, you’re going to allow them to place it. Will it be available on the mobile and desktop, you know, for developers, what events you’re going to be firing from your component that they can listen for, and be able to specify and how our end user is going to interact with the components and is it consistent with the rest of the user interface. These are all really important things that when you’re designing before you write any code that you’re starting to flesh out. in some detail

06:00

Josh: and tell me more about user centered design itself. Like what does what does that principle really entail?

06:07

David: So user centered design, for me, it’s fairly common sense. And I say that from someone that doesn’t come from that background. My philosophy is if you have access to people that do user centered design for a living, you should use them. But equally, you shouldn’t be put off from taking some of those principles and applying them yourself if you’re an individual or from a small company, because really, it means putting yourself in the shoes of the people you’re developing for, and iterating and focusing on those users throughout the design process, and making sure that you’re learning from those experiences and constantly improving what you’re delivering. So by designing on paper first, you can iterate much faster.

06:47

Josh: And so sticking to that design phase, like there be you know, prior to putting code to it, so to speak, what are some of the tools that you found useful during that phase?

07:00

David: So for me, the tools I really liked were things like the Lightning Web Component playground. For those that don’t know, if I take a step back for a moment, there are lots of custom components that I’ve seen that stand out on the page in a bad way. And it’s typically because Salesforce designs its components to be consistent by applying a design pattern that they’ve called lightning design system. So these are brand and product design guidelines, where they show you patterns and component blueprints that you can reuse. But it’s a new concept to you as a developer who’s used to developing in visual force that can be quite hard to adopt. So the Lightning Web Component playground was easy for me to quickly prototype, what my component might look like. But I also found a pen and paper quite easy to quickly prototype what my component might look like in the context of a bigger page. And I think often people say, Well, I don’t do UX design or UI design for a living. So I can’t do that. But really the concept of pen and paper is if you can draw circles, triangles, squares and rectangles, you can draw a mock page layout quite easily. Because really, what fundamentally, what we’re trying to do is stop you from rewriting code, which will take you longer and be more expensive. So that’s fundamentally where I’d start. And then if you want to get more advanced, you can use tools like sketch. And one thing I didn’t know until I started this process was the Salesforce Lightning design system provides a UI kit for sketch that you can download from that website.

08:37

Josh: And kind of going back to that first part for a second, because when you’re saying going to pen and paper, you’re not trying to create some kind of, you know, brilliant illustration that’s going to allow a customer something like that, you’re probably doing more of like a mock up of something that’s in a user interface way illustrating the features that you’ve already kind of defined through the ideation phase.

08:59

David: Correct. So Things like a drop down list might just be a rectangle, that is that rectangle gunner as the drop down is going to be on the left hand side of your component on the right hand side by sketching it out, I can show people to solicit their feedback on which position they think might be easier to understand.

09:16

Josh: And what kind of feedback loop Do you think there is between using something like the lightning Web Component playground and, and kind of improving back on that, you know, making sure that you’re, you’re reusing those patterns into the UI that you’re actually going to come down with?

09:31

David: Maybe rephrase the question for me, Josh, is that you’re asking for your custom components, how they’re reused, or the standard base components,

09:39

Josh: sort of like so that that gap that you’re talking about, like coming from a Visualforce you might be tempted to just try to go blank page and kind of start on your own. But do you find that the Lightning Web Component playground is also not just useful from a point of view, but from like an educational point of view of knowing what the base components are supposed to look like and and how they’re arranged and used?

10:01

David: Yeah, for sure. In fact, in my component, I did have a principle early on that said, if there was a basic component available, then I needed to use it. Even if there was some compromises around look and feel, or there might have been some gaps, try and reuse those components. because really what I’m trying to do is make my life easier. And I know those components will get better over time.

10:24

Josh: So don’t invest the time unnecessarily. How do you think you keep the lightning design system sort of first of mind when you’re working with these tools?

10:34

David: So for me, the lightning design system website, where they have blueprints was where I went first. So I guess a good example, it’s in my component, I had the concept of or I knew the users wanted the ability to filter. Gotcha. So show me clusters of interactions, but sometimes I don’t want to see tasks. I just want to see cases knowing a good design for how you do filters is not my forte. But luckily Salesforce has a lot of people working for them where it is their forte and they’ve thought about this long and hard and had access to advisory boards and surveys and things like that. So these component blueprints are pretty well thought out and are used consistently throughout the standard lightning desktop experience. So for me, the filter needed to replicate as much as possible those blueprints because it would be more intuitive for a user who is used to say filtering a list view and Salesforce it should work in a similar way if not the same way.

Josh: I remember asking I think her title is like like design evangelist was somebody I kept running into in conferences Jina and I want to say is her name I’ll see if that’s correct. If we do a shout out, and I asked her, like, why are a lot of these examples that you give kind of complicated like sometimes I just want like, you know, that bulleted list, and I have this like really kind of complex you know, business card response was like, because that’s that people want the real world UI that we use here at Salesforce. And then you can kind of strip down to what you actually need. Did you run into similar situations?

12:13

David: 100% I think the best thing that the evangelist team that at Salesforce is starting to release, things like the Dreamhouse, app, and ebikes these are fully functioning applications that moved away from the hello world examples, which are equally important from a learning capability into more fully functioning end to end apps. Because I loved the podcast you did with Greg, where, you know, I work in the same mentality that it’s really learning from other people and being able to copy and paste that code that you know, gives you a leg up in learning something new.

12:51

Josh: Okay, so you know what you’re building, you know, what it should look like and you’re in the lightning Web Component playground itself. What are the other tools Now that we’re actually getting into full on development that I should keep in mind.

13:04

David: So for once I had a mock up of what I wanted it to look like. And I focused on the end user experience of the component being on a page, and also how an administrator would interact with it at design time in the app builder. For me, the beauty of Salesforce dx is then I’m just now in Visual Studio code. And I’m using local development with lightning web components. Because one of the key learning experiences for me was the CSS. So being able to change things really quickly. And being able to test that locally, I sort of improved my productivity No, no, because I made lots of mistakes.

13:42

Josh: Did you have access to local development through the whole process? Or did you kind of start back in the world of having to put every single CSS change back to the server and then end up with local development?

13:54

David: Yeah, so I started looking at this before the local development was available even as a beta So, for me, pushing changes and then logging in refreshing my screen worrying about whether it was cached or not, you know, for every change I was making may have only taken 20 seconds, but then multiply throughout the day, I quickly got frustrating. So moving to local development saved a lot of time. So anyone that’s not sure whether that’s gonna have productivity improvements, I would say that, if you’re an experienced developer, it’s minimal. But if you’re learning like me, it will save a lot of time.

14:27

Josh: Yeah, and this kind of does repeat some of the stuff that in the conversation with Greg, like, for instance, even but my best quote unquote, you know, when I’m when I’m doing CSS and doing JavaScript, I just have this like mentality of I need to do every single change and then see, you know, every single change, so I definitely get in that loop. And two of the big things we’re talking about here, lightning web component, playground and local development, they definitely I think, fall into that camp of if you’re not using these tools as Greg himself put it, you’re just doing it wrong.

14:56

Yeah, definitely make your life easier, not harder.

14:59

Josh: Right. Exactly. So how was it like because part of your application or part of sorry, part of your component is using d3.js for the visualization. What was it like incorporating a third party library like that?

15:12

David: Yes, surprisingly easier than I thought. So the component uses two things that uses d3. js for the visualization aspect because I need to be able to scroll backwards and forwards through time. And plot records on a scrolling graph. And it uses moment JS for comparisons and date differences. It was surprisingly easy in the sense that, you know, once I decided on the look and feel, again, why reinvent the wheel, d3 is a library that has lots of examples online and some of the concepts of what I wanted to achieve to mimic things like the health cloud timeline are all very well documented. So in d3, they call it the brush and zoom having something at the bottom that I can slide kind of automatically scales the graph on the top Super easy examples to follow along. It wasn’t quite copy and paste. But really all I do is plug in the trip to the server to retrieve some records that I wanted to plop.

16:10

Josh: Gotcha. And again, you are copying and pasting from examples that, you know, you’re not a UX designer. I’m not a UX designer, but the people who came up with those samples are UX designers.

16:21

David: Exactly. So for me, it was more making small tweaks. And when you start thinking about scale and performance, there were some aspects I wasn’t quite happy with. Because remember, when you’re copying someone else’s code, they’re really designing for their own use case, right? And I like the UI of the health cloud timeline, but their mantra wasn’t to plot cases and tasks, which tends to be on a different scale or together for enterprise customers. So some things had to be tweaked slightly, but nothing too major.

16:49

Josh: So we’ve got through ideation to design If you’re thrown in a couple extra libraries, you’ve got this thing in dice interactive and working. What are some of the consider When you’re getting to that rubber hits the road moment when it comes to handling things like performance.

17:06

David: So when Salesforce moved away from classic to lightning, I think it was fairly well documented that performance was often a concern in the community. And I think the reason for that is each component that now makes up a page in lightning uses XML HTTP requests to send and receive information from the database. And each component can individually send those x HR requests, making the lightning interface susceptible to things like network latency. So I think Salesforce as a company takes on a lot of responsibility to make those requests as efficient as possible. But so do end user developers, because I think Greg was alluding to it in his podcast that we don’t really know how developers are going to use the lightning design system, the Lightning Web Component framework. So we’re all learning together. And what I had to do was start thinking About how do I look at performance and scale because I can’t just plop an endless number of records on a timeline, I need to be able to give an administrator some boundaries to limit the number of records returned with date ranges. So performance then impacts how I design because now I’ve got to keep you properties at design time, to be able to say, how far back in time do you want to go? How far forward Do you want to go? And as a developer, limiting that number to a maximum? So you can’t go back 99 years, but maybe three years is a good compromise. And that comes in with a lot of research we were doing around what are some of the biggest enterprise customers we have? How many cases a week do they have? How many opportunities a week do they create? So that we could start parameterizing you know, a maximum number of records that we should deal with? So you know, things like page layouts? Do you really need 30 components on a page is that user friendly. So I think admins developers will take some ownership when it comes to performance as Go. But the most important things for me came around caching what non transactional data could be cached. Because what I was trying to do is knowing that each XHR request is not going to perform well, I needed to make sure that I was caching a lot of the data, as much data as I could in the browser.

19:19

So in a timeline, if people go and install it, we have a tooltip concept. As you hover over a record, it displays some data to allow you to identify the record you need. If I did a call out back to the server, every time you did a mouse over event, it would be super slow. So we needed to think about what tools were available to us to make that super snappy.

Josh: It’s an interesting perspective, because, you know, when we’re working in an Ajax XHR kind of environment, I think there’s this kind of assumption that that transaction is going to be you know, super quick, it’s like, it’s always gonna be, you know, milliseconds like fast, but it’s kind of sounds more like the keep every one of those requests sacred assume that that latency might come at any moment?

20:10

David: Absolutely. I think for the tooltip example, I could have reached out back to the server, but the user experience would have suffered. So just by thinking about it a little bit more at design time, I could then design for something that I think is much faster. So talking through the example, Salesforce gives you data services, like the UI API does this occasion for you. So you’d be crazy not to use it. So I could, you know, with 10 lines of code, and a record, Id display a compact layout, where Salesforce does all of the hard work of retrieving the data and caching it locally. I don’t have to worry about it. But then I have to design for the fact that the UI API doesn’t cater for all object types yet. And so if you think about task being something that I wanted to plot on the timeline, putting in a record ID to the UI API would have returned an So I had to have a fallback mechanism. But the fallback mechanism was showing me a field I had previously retrieved in a query. I didn’t have to reach back to the server to go and get it.

21:16

Josh: Gotcha. Thinking about those things can really impact the effectiveness of your component.

Well, and also coming back to what you’re talking about from a reasonable bout of data. I think that’s interesting, because this is a very common problem that front end engineering gets into it goes back to conversation I was having with Kris Gray about how like the holy grail is a really fast data grid, because everybody wants access to their records, they want access to as many records as possible. And they also want it like right now kind of thing. So. So it’s interesting to me that you basically have you know, that problem once again, reasserts itself with the research that you’re doing to what’s a reasonable amount of data that an enterprise user would expect. How did you handle testing and development to replicate that in a way that you felt like The performance was going to stay within that reasonable amount of data.

22:04

David: Yeah, good question. So I was fortunate enough to be working with enterprise customers to be able to give me a sense verbally of the data volumes they have on a day to day basis. So we came up with a concept of, well, what are the types of records you’re gonna want to see on a scrollable? timeline? So things like cases, tasks, calls, emails, opportunities, campaigns, because you’re sending emails to them. So we came up with a list of I think, 10 of the big ones. And then we said for each of those, how many a week do you get on average? So that gave us a number. And I think we’ve blogged about it, how I came up with that number from those conversations, then it was a case of, for me just using Data Loader to pump in that number of records across those objects, which interestingly highlighted a number of issues straight off the bat, what kind of issues so the biggest issue for me that ironically, I still have with a component, so anyone that wants to help please, please a pull request is at the moment, in order to visualize the clusters of records, we’re plotting a dot for every record, which when you have a few hundred is fine.

23:11

But when you have a few thousand, you start to become just like this big messy blob, which isn’t particularly nice. So when we blogged about it, we started looking at Well, that doesn’t scale particularly well, clearly, we need to think about how we visualize those records differently. And we’ve come up with a concept of when you log into GitHub, you see your code contributions highlighted in this nice heat map, right? Maybe we could use that concept instead and group activities by week instead of individual records. So by making that small change, I’d still have something very visual, but that would scale a lot better. So again, it highlighted just by loading methods, a number of records to simulate worst case scenario.

23:55

Josh: And I think this goes back to one of those great like axes. Like, it’s like don’t assume production data, right? Like, as soon as you can, you know, have that access to as close to one to one as possible. Because, I mean, first of all, you can actually predict what your performance is going to look like, because it’s it’s actually staring at you in the face. But you would never have actually visualized that problem unless you’d actually seeing the correct number of records.

24:20

David: Exactly. Right. Exactly. Right. It’s something that’s hard to predict upfront, but now I know it’s there. There are options to to get around it.

24:28

Josh: And any other tips for testing in general, not just when it comes to things like a reasonable amount of data?

24:34

David: Good question. So I’ve been blogging about this journey in component design for a while, and we can cover off the ideation design and build to testings Next on my list, Josh, to be honest. So at the moment, if you’re following the GitHub repo, I’ve created the boilerplate templates for just tests and for Apex tests, and I’m going to be blogging about making them effective. And that will be interesting because I’ve never tried just to With a third party JavaScript framework before, so if you’re interested in having a laugh and seeing me make less mistakes, follow the GitHub repo.

25:08

Josh: Now rest assured, we will have links to David’s code. We’ll link to his Github repo. We’ll also link to his blog posts that go into more detail about his experiences when it came to learning and developing a lightning web component. And before we go, David has one final piece of advice there.

25:25

David: I think the only piece of advice is I come across a lot of people who are reluctant to share experiences and code online with the community. I think they’re probably worried about being criticized for not being an expert in something. I would definitely encourage anyone listening if they have a point of view, get it out there and learn from others is the best form of learning for me and I personally think the Salesforce community in general is super supportive. So please let me learn from your code and post it online.

25:54

Josh: There you go. People go forth and code and share your experiences about it, whether they’re on Github or blogs or or YouTube, anywhere you like. And that’s our show. Thank you for listening and a huge thanks to David for the wonderful lightning web component and his conversation. If you want to know more about this podcast, head on over to developer.salesforce.com/podcast, where you can see old episodes, transcripts and links to your favorite podcast services. We’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.