Summary
In this episode, Rob and Michael discuss the concept of a kitchen sink app and how it can be used to jumpstart development and conversations with customers. They explain that a kitchen sink app is a design-driven approach that utilizes a template or prototype to envision what will eventually be built.
Detailed Notes
A kitchen sink app is a design-driven approach that utilizes a template or prototype to envision what will eventually be built. It's a neutral application that can be styled for multiple devices, making it a versatile tool for development and conversations with customers. The hosts explain that a kitchen sink app should be built with a template or prototype that can be used as a foundation for all work. They also highlight the benefits of using a kitchen sink app, including the ability to show customers how their application will look on different devices.
Highlights
- A kitchen sink app is a template or prototype that jumpstarts development and conversations with customers.
- It's a design-driven approach that utilizes a template or prototype to envision what will eventually be built.
- The kitchen sink app should be a neutral application that can be styled for multiple devices.
- It should be built with a template or prototype that can be used as a foundation for all work.
- The app should be able to show customers how their application will look on different devices.
Key Takeaways
- A kitchen sink app is a design-driven approach that utilizes a template or prototype to envision what will eventually be built.
- It's a neutral application that can be styled for multiple devices.
- A kitchen sink app should be built with a template or prototype that can be used as a foundation for all work.
- It should be able to show customers how their application will look on different devices.
- A kitchen sink app can be used to jumpstart development and conversations with customers.
Practical Lessons
- Build a kitchen sink app with a template or prototype that can be used as a foundation for all work.
- Use a kitchen sink app to show customers how their application will look on different devices.
- A kitchen sink app can be used to jumpstart development and conversations with customers.
Strong Lines
- A kitchen sink app is a design-driven approach that utilizes a template or prototype to envision what will eventually be built.
- It's a neutral application that can be styled for multiple devices.
- A kitchen sink app should be built with a template or prototype that can be used as a foundation for all work.
Blog Post Angles
- The benefits of a kitchen sink app for development and conversations with customers.
- How to build a kitchen sink app and use it as a foundation for all work.
- The importance of showing customers how their application will look on different devices.
- The design-driven approach of a kitchen sink app and how it can be used to envision what will eventually be built.
- The versatility of a kitchen sink app and how it can be styled for multiple devices.
Keywords
- Kitchen sink app
- Design-driven approach
- Neutral application
- Styling for multiple devices
- Development and conversations with customers
Transcript Text
Welcome to Building Better Developers, the Develop-a-Nor podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are Building Better Developers. We're Develop-a-Nor. We are in Season 23 and we are building better habits this season. So this time around, we are going to talk about something that actually Michael has talked about many, many times, particularly in the last season. I think we've really gotten into detail on it before, but we're going to swing back around. It's the idea of a kitchen sink app. And really what we're going to look at is using sort of like a template or a prototype to really like jumpstart your development, but also to jumpstart your conversations with your customers. Before we get into that, we should introduce ourselves. So I'll start by introducing myself. My name is Rob Brodhead, one of the founders of Develop-a-Nor of Building Better Developers, also a founder of RB Consulting, where we help you wrangle in all of the technologies out there. We do things from, we start with like an assessment. We figure out where you are. We walk you through some things, talk about your business, understand your business, your goals, and then we find ways to marry the technology you have and the technology that's available with where you want to go so that you're prepared not only when we walk away for today, but six months, six years down the road. Beyond that, okay, it's technology. You're going to have to look at stuff, but we do put things in place so you don't have to reinvent the wheel five or 10 years from now. We do that through simplification, automation, integration. We find ways to leverage all of the right technology. It's not necessarily build versus buy. It's not necessarily a monolithic approach versus an ad hoc kind of approach or a la carte kind of approach. It is finding the best way to put those things together and to pick the best solutions out of how it works for you, for your organization. Good thing, bad thing. This is one that actually goes back to what I just talked about in Technology Sprawl. I am working with a new customer and they have the sprawl to end all sprawls. They have had Wild West. It's a big organization. They've got a lot of stuff going on and they've got a lot of very smart people solving a lot of really complex problems, which means a lot of times when you're solving a complex problem, you're going to think that I have to solve this in a very customized way. Not entirely wrong, but that doesn't mean that you can't leverage the work of others. They haven't done that. They have built this huge thing and sometimes people move on. There is zero people in the world that know all of the things going on in this organization. There just isn't. There's a lot of stuff out there that people have. Nobody knows anything about it, basically. They just know that it's out there and that's about it. That's the bad thing. This is a nightmare of sorts. The good thing is there's a lot of work to do. I am not going to get bored anytime soon. When you have a fire of this magnitude, anywhere you start is at least you're making progress. It's one of those that's like you have a ton of work to do. You can really start literally anywhere. I don't think anybody's ever going to come back and say, no, you shouldn't have worked on that. You should have worked on this instead because it's all super critical priority. It's one of those like, okay, the bad thing is there's a lot of work to do. The good thing is you can start anywhere and you're immediately going to be making some progress for it. I am going to start with my big world of things I need to do with passing stuff over to Michael so he can introduce himself. Hey, everyone. My name is Michael Molloch, one of the co-founders of DeveloperNUR, Building Better Developers. I'm also the founder of Envision QA, where we help small to big size companies and healthcare professionals build software that meets their needs. We can help you with customized software. We can help you with existing legacy software. Our main focus is really building software with testing in mind. Everything we build is test driven so that any changes to the software we know immediately when something breaks versus getting in front of the users and you kind of lose that, you know, your credibility when software goes out that's bad. Good and bad. I'll start with the bad. Working on a project, we're kind of at the tail end of it and there's no clear direction from the business as to where we're going or if we're even going to be working on this project in the months to come. So we're kind of in that little limbo and you kind of get in that anxiety of, you know, are we going to be working on this or not? So it's kind of one of those things where it's like, you know, do you jump ship or not? The good thing is kind of knowing that's coming along, working with other companies, trying to bring in more business and also looking at some additional skill sets that I can build into and expand my company into those roles. So let's talk about a kitchen sink app. And I want to have my focus is how you utilize this as a way to envision sort of as a more like in the requirements and design phase as a way to envision what you're going to eventually build. Now, some of it is definitely some of this is very much design driven. This is very much about design because to me, it goes back to really like the core of component development and object oriented approach and stuff like that, where even in a visual sense, it makes a lot of sense to have objects and controls. And most frameworks embrace this now. So there are things you have, particularly if you look at the world of, like, for example, whether it's angular or bootstrap or I forget, not flutter, but I think it's all of those different things, those different libraries out there. I forget so much. I always like mix and match their names. They're basically the same thing, just slightly different in the syntax. But the core thing is that like, this is what a table looks like. This is what a data entry form looks like. This is what a menu item looks like. This is what a button looks like. Those kinds of things. Those are all controls. And those are all going to have a specific look and feel for your application. Now, this holds whether you're using web applications or whether you're using any other visual, like a desktop application. Back in the day, when I built a lot of desktop applications, one of the first things I would do is have a page and I would go through and I would build controls that I was going to use all through the application. And it was the kinds of things where I was like, with this control, I'm always going to have like maybe a micro help kind of thing or a specific kind of label thing. A lot of times I would group control. So I would have things like, this is what an address form looks like. This is what a contact form looks like. This is what your basic input fields look like as far as labels and the width of the text entry. This is what buttons look like. This is what a visual container looks like. In the web world, it'd be things like spans versus divs and field sets and forms and some of those kinds of things. It's like, do I have a different background color? Do I have a border? Do I have a dashed border? Do I have an inset? Do I have an outset? All of those kinds of design choices. I would do that from the start and that's where this kitchen sink app kind of thing looks like. It goes to the idea of having a page in this sense. You have a page or a form and you have all of your controls live there. So you can think about when you're building your application. Let's say it's a standard web application. You probably have a, and we'll just for lack of better terms, we'll just say, let's assume you have a header, a footer, some sort of navigation, menu type items. You've got form entry fields. You've got reports. You've got table kind of stuff. You've got search forms. You've got filters. You've got lists. You've got drop downs. Those things, there's all these things that are part of your application, part of what you're going to deliver. And so what you do is you build a page. You can just throw random data into there basically, but the key is to show all of these controls and then for you to be able to see all of them and decide how you want to do it. Because there's going to be some things that you're going to say, particularly in the world of web. And this happens really in, I think, almost every user interface framework and structures out there. You start with a panel. You start with some sort of the base. It's like the body of an HTML document or some sort of canvas that you're painting these things on, depending on what you're using. It's actually called a canvas. And that is like the default for everything. And so from there, you've got the default for everything, which you want to build that up. And then you want to start with all of your specific controls. Say, well, this is how this thing differs. This is how I want to approach this. Now you may have something that is very complicated where it's like, I want to do this. I've seen it very often. You see it three different ways. I want to do it for like a phone. I want to do it for a sort of standard mobile device. And I want to do it for a big honkin UI when I have almost infinite real estate. The nice thing about doing this kitchen sink app, whether it's a web application or a graphic application, is what you're doing is you're within this. These are your, in the object-oriented world, these are like your core objects. So what you can do is you can actually inherit from the control for each of those and then just boom, you bring in all the stuff that you need to do. And in the web world, that's called cascading style sheets. Basically, that's your CSS. As you're going in there and you're saying, these are all of my core objects that exist in the world of HTML. Your headers, your anchors, your divs, your tables, your forms, all that kind of stuff. But then you're also adding within that your classes, your style classes that you're going to put on top of these or use within these. So there are going to be things like, you may have like this, if it's a button, that's great, but if it's a informative button versus an action button, enabled versus disabled and those kinds of things that you can build all that stuff in, put it all on a page. And the nice thing is, yes, you can then take that and use that as the foundation for all of the work that you do and save yourself, copy and paste and things like that and making sure that all of these things sync up properly. Not only that, the maintenance side of it. So if the customer suddenly says, I don't want that red, I want this other red, then you can just change that and it's like, boom, everything just inherits that chain. That's sort of the stretch goal for this. But the other thing, I use that C word, customer, is you want to be able to take this and show it to them to some extent to say, early on, say, this is sort of how these things are going to look. This is what a standard report page is going to look like. This is what a data entry page is going to look like. So your kitchen sink, this is where it becomes maybe an app and not just a page, but you may have three or four different pages to say, this is what this style looks like. This is what this style looks like. And you see that if you want a good example of how that kind of thing can be useful, go out to WordPress, go to one of their themes, and you will see effectively the same thing as they have these themes, which is essentially CSS because usually it's all of the default standard WordPress tagging and all that kind of stuff just with a CSS slapped on top of it. So those are the kinds of things you're going to have. A bonus before I pass it over to Michael is another place to look that we've both experienced before and it is really a useful place to go is go look up CSS Zen Garden because it is really it is the same HTML and they just put different CSS and it looks dramatically different, which is in itself is that Zen. It is very like relaxing to just look through those designs, but it's also very helpful because you can steal from some of those and say, oh, I really like that style of text or whatever they're using. And then you can utilize that within your own site. So I've laid a lot out there and now I'm going to let Michael sort of like, you know, digest some of that and add all of his little sprinkles on top. Thanks Rob. I really like how you set up the kitchen sink app, especially the way you were talking about using the styling in. If you look at the progression of the web, basically how the web and building applications has kind of transformed over the last couple of decades, we went from building nothing but desktop applications and you had to kind of had this look and feel for Windows. You had this look and feel for Mac and Linux. Everything kind of was structured like if you were doing Java, it was kind of all Java apps look the same regardless of what platform you want. Over time, we started having the internet, building webpages, having more design structures and got a lot better. We now actually could take those marketing documents we had for companies, those branding documents and actually build the brand into our applications, into these designs. And then we got into the mobile world and all these mobile devices. And now we kind of had a paradigm shift. So we went from building desktop applications, building web applications, building mobile applications. Each of these at a time was standalone applications. They did not play well together. You could not write one program and have it apply to all. Well, here we are today and there are so many different frameworks and languages out there now where you can write one application and push it out to multiple devices. So the cool thing is, especially with this kitchen sink app, is you can pick one of those languages or one of those frameworks and build it. And then at a push of a button, you can show your customer, hey, here's what a desktop application will look like. Oh, but by the way, if you want to translate that and also have it as a web page, click a button. Here's what it looks like on the web. Should look very similar. And then again, bring up on a mobile device. Here's what it looks like on mobile. It can be native applications. They don't just have to be here's a web browser. We're trying to conform it to the browser. You can actually say, hey, this is what it looks like on Windows. This is what it looks like on Mac. And ironically enough, they actually look like their Windows device, like their native applications. But in reality, it's this kind of neutral application you've built and you're using all these stylings for multiple devices is awesome. It is so much fun. I love this transition. But through this, through the 90s, it was hell. In the mid 2000s, we started having cross platform or cross mobile development because of a couple of lawsuits that thankfully opened up some of the architectures on the different devices. So we were able to start doing things at a native level, but for multiple devices. So you could actually create a mobile app that worked on both iPhones and Android devices instead of just having OK, I build an Android device. OK, I got to duplicate the code base and create an Xcode or an iPhone application. So this conversation we've been having about styling and kitchen sink apps is more back to that styling, that Zen garden, because we can now build those applications in a way where we basically have a template. Every device has the same kind of controls. You have tables, you have buttons, you have input fields. How it looks is what you do with your styling. So you can create multiple different styles at a push of a button, just some customizations. So if you build this kitchen sink app right, it should be a very simple copy paste, change some styling, show it to your new customer, and it should look very similar to what they currently have if they have anything at all. One interesting note is if you use web tool, if it's a web application and they have no idea what their styling or branding is, you could use tools like Chrome or Safari, open up the developer tools. And over on the right, when you go to a web page, you can see all the CSS, all the colors, all the branding right there. So you can go scrape that or literally copy that, put it into your kitchen sink app. And now all of a sudden, your design app looks very similar to that company. So there's a lot of benefits to doing this. And it's a lot of fun. It really from me personally, I like playing with that. It's like, oh, hey, let me go do this. Let me see how this works. Or if you do it right, the cool part is the web language, I guess where we're at now, like 3.0 or hasn't really changed in a while. And even when it does change, they really only introduce new tags. They don't really take away too much. There were a few things they took away for security reasons to help avoid phishing and spyware. But the majority of the framework, what is a web document, what is a mobile application, it's pretty static these days. That doesn't change. All the other stuff changes, all the styling changes, all the JavaScript changes, all the stuff behind the scenes that actually helps show those controls is really what's important. And that's what you just kind of want to go through and refresh yourself on from time to time, because then you have this app. You can just go, hey, this works. Pull it in, change from CSS and then present it to the customer. So that brings us to our challenge for this episode for this week. I think, and this really comes actually from something I was doing to do a little lecture, a little technology session. But I think it's worthwhile for each of us to do this. And I'm actually going to go back and flesh this out a little bit more. Is particularly if you're doing web development, create a kitchen sink app for your style sheet, which is all it is. It's an HTML page, maybe a couple, but it's effectively starts with one HTML page and one CSS document. Now, you may have an application that's rather complex and it needs eight different CSS documents. So be it. Put them in order, particularly like, let's say you're using, like I use a lot. I use Bootstrap very often. So I'll have the Bootstrap libraries and then include your customization of that, your CSS library on top of that. And then have an HTML page or series of pages that is it should be the views of stuff, the views of data that your application has. And it could be things like a standard homepage, reporting page, filter search page, things like that. It may be like a profile page, log in, log out, some things like that. Now, some of these, I think, as you put these together, you will realize that there's probably the idea of the general framework of your page, headers and footers and navigation. And then there is like a main section, let's say a content section that is maybe report specific or data entry specific or dashboard specific, you know, things like that. So that you would, the idea is for you to start thinking through this and say, well, what really is, what are the core elements that I'm using to build this interface? Now, I'm using the words CSS and HTML page. If you're building a desktop application, then build, take what you've done and build a stripped down version of your application that is just the GUI. Now, there are other things we can do with this idea of kitchen sink apps, but this for this app, you know, this exercise that we want to do is we want to have a sample of the interface that ideally is going to be something that when you're done with this, you'll have something that you can now very quickly play around with it and say, what if I did this? Like, what if I wanted to change the color, you know, the general color schemes of my application, what would that look like? And how would that flow? It's the kinds of things that I think is very good. And Michael sort of got into it. You can do this within Chrome and Safari and a lot of the browsers. You can start tweaking stuff and see like live very quickly. You can tweak a few values and the next thing you know, it's like, oh, this is what that app, this is what it would look like if I did this. This would look like if I did that. But I think it's nice to have the full expanse of what of all the different controls or objects in your application and do that. So that's your challenge is to build that out. And if you can put it somewhere, if you want to share it, I would love to see it particularly. The interesting thing is how complicated you don't have to give us the details, but I'd be really interested to see like how complicated you make if you're using the CSS, how complicated you make that. Do you have, you know, five or 10 things? Do you have hundreds of things? Because it really does get, it can get very long very quickly if you have a lot of different controls and a lot of different customizations to it. But I think that's a really good exercise. And you know, before we come around to next time is spend a little bit of time and play with that. If you want to go flashback to our prior lesson, maybe do a Pomodoro or two where you are just focused on building this kitchen sink app out. That being said, we will wrap this one up. I want to make sure we can give you some time to get back into whatever that work is that you're doing. You can build your kitchen sink. Shoot any feedback that you have. If you have ideas for some other building better habits kinds of topics, let us know info at developinure.com. You can reach us on X at developinure. There is a developinure page out on Facebook. You can go to developinure.com and leave us, there's ways to leave forms and contact us so you can give us some feedback that way. You can like us and comment and all that kind of good stuff wherever you find, all the places that you can find podcasts. You can also go out to YouTube slash developinure, actually the developinure channel there. You can see this plus lots of other stuff and lead us feedback there. That being said, with the big breath, we get to wrap this one up as well. So go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers to develop a newer podcast. You can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.