Find this Podcast “Creating a Minimum Viable Product with SharePoint and Angular” on the ThreeWill Soundcloud, Stitcher, and iTunes.


Danny:Hello and welcome to The Two Bald Brothers and a Microphone Podcast. This is one of the bald brothers Danny, and I’m here with a Matthew Chestnut. Matthew, how are you doing?


Matthew:I’m doing well Danny.


Danny:Great, I love that you’ve been busy recently. I appreciate the time to catch up with you, our little quarterly pow wow here. We’re going to find out what you’ve been up to.


Matthew:Yes, I think we missed one last time.




Matthew:Yes, I think we missed one last time. I did a blog post last quarter, so this has been a little while since we’ve gotten together to talk.


Danny:Yes, I appreciate this opportunity to catch up with you. It sounded like when we were preparing for this podcast, it sounds like for the clients that we’ve been working with for a while and helping out in various ways that sort of come up, and they want to see something.


We put a blog post out this week by Bo about a minimum viable product, where they want to create something really quick and get something out there so that they were able to work around it and get something up and out.  It seems like there’s becoming a pattern of where we’re using SharePoint as the backend, and Angular along with that, where we’re able to get something out sooner rather than later. The recent project that you’re working on sounds like you’re doing that as well.


Matthew:Yes, well it’s coincidental. I am working with Bo on this particular project, not surprising. This is the second or third time we’ve come across this MVP, this minimum viable product concept.


It was relatively new to me. I always think of an MVP as being the best in class, the best in the world. In the work we’ve been doing, we’re trying to get some projects done pretty quickly for our customer. It might be that the customer may not know the full breadth and depth of what they’re trying to accomplish, but they know enough to get started.


We’ve been using SharePoint as the backend, simply because the infrastructure that it provides as far as data management, security, search, all the standard stuff that we know and love about SharePoint. Because those features and functionalities are there, all we have to do is focus on getting the data, the data model in place, that we can store the data and then, of course, the user interface, so we can present the data to the user. It works out great, the SharePoint Microsoft 365 or on Premise.


Danny:And then the Angular part of this is, is that for the UI, for the presentation piece? Is that where that fits into this?


Matthew:Yes it does. We started with Angular a while back, and a while in computing years is months ago, just a couple years ago. It seems like it’s been forever, but yes we’ve been using Angular. Of course, their SharePoint Framework is available as well. What the customer wanted is ultimately or perhaps possibly decoupling from SharePoint and running this with a front-end against perhaps SQL Server in Azure in the cloud.


We didn’t want to do anything with SharePoint Framework because that would tie us more closely to SharePoint, so we’re loosely coupled. The advantage of Angular or at least the technology that we’re using, the way we’re implementing and accessing the data through the SharePoint patterns and practices, JavaScript library to SharePoint is it gives us the ability to plug in a different data layer if we so desire later on.


Danny:Nice, very nice. For these projects, is something being done within weeks or is it months? What does it look like as far as the timeframes for these projects?


Matthew:Yes, that’s a good question. What does minimal mean? When you talk about a minimal, what is minimal? It ends up being a combination of what is the overall big picture; it’s just a fraction of that. For example, I would guess if we were to do every feature that this particular customer wanted, it might be a six to nine-month project.




Matthew:What we’re trying to do here is within a few sprints maybe two to four sprints, that’s anywhere from four to six weeks of work, get something functional and operational.


The advantage that we had is during the proposal process, and during the estimation in trying to figure out what it is the customer wanted, this is a rather unusual product. It’s not like an invoicing or some of the standard business things; it’s more of a management of business operations.


When they were working through the prototypes of this, Bo would come up with prototypes of the application using some of the same technologies we’ve used in the past. Granted it didn’t do a lot of the nice things behind the scenes, it was all mock data, just storing it locally.


It exercised the UI in such a fashion that we were able to demonstrate to the customer that we understood what they were asking for, we fed it back to them in the form of a UI. The customer got the ability to say, “I want this changed, this moved around, this added.”


That helped with the estimation and figuring what needed to become a part of this minimal product.


Danny:It sounds like, did it use the Angular piece just to do some prototyping and screen mockups, and that sort of thing?


Matthew:Yes. We had done some other projects, and we figured it would be a nice continuation of that same technology. We pretty much had a layer of a programming model if you will if we add a few lists here, we do a few things here with the navigation and the user interface; we can pretty much have an application up and running in just a couple of days.


Then it was more of the fine tuning and specifying specifically what the application needed to do based on what the customer is asking for. It was a very rapid prototyping phase.


Danny:Is this going to be consumed by a web browser, from a mobile device? What’re the plans for how someone is going to use this?


Matthew:It’s going to be a web browser, so it’s going to be a business operations type thing. There’s nothing preventing it from being accessed by a smaller device like a tablet or a phone because we are using some of the bootstrap classes and et cetera to make it responsive.


Although the quantity of information on the screen, there’s information about a product, and activities, and people, and roles, and all of this; it’s probably not as mobile friendly just because of the volume of data. It’s going to be targeted to our desktop browser.


Danny:Very nice, very nice. Are these new technologies for you? It sounds like maybe you used a couple of them before, any pieces of this new to you?


Matthew:Yes. It’s interesting because of some of the base layers of the technology, of course, we’ve been using for a long time, SharePoint, Angular, JavaScript. It’s when the customer says, “And I want this whiz-bang thing to do this.” Sparkle, and twirl. And do all kinds of things.


It means we have to come up with some controls, some user interface controls, how things look on the screen. It might be a tree view of data an infinite number of levels deep. How do you deal with that when you’re talking about data that might be two, or three, or four different levels deep and you’re clicking through it, and you want to save that data? There’s a control for that.


There’s also the ability to link information together and present that data on a screen so that when you have to update a certain part of the data, you’re not necessarily having to refresh the entire screen.


We’re getting smarter on how we partition the data, partition the UI, do the data model, do the data model layer, all those things that go on behind the scenes that to the business user they don’t care, but to the technology people, we do.


It gives us the ability to move quickly. If the customer says, “Oh, I like the way you did feature X, now I want feature Y and Z to work pretty much like that except with these few changes.” We could do those changes pretty quickly.


Danny:Is the Angular piece of this, is this running in Azure? Where’s that Angular piece, where’s the code running?


Matthew:The way it works in this world that we’re using SharePoint is the actual “program,” which is a set of JavaScript that gets transpiled from this deployment process, it’s living in the SharePoint virtual file system. When you go to the URL,, it redirects you from the standard SharePoint page to our custom page.


From that point forward, you’re running the code off the SharePoint virtual file system. Because SharePoint acts as a file system, we don’t have to worry about uploading to an operating system like a Windows OS or a Linux OS in a certain directory. It’s just running straight from the SharePoint world.


Danny:Because Angular is a JavaScript framework I’m assuming.


Matthew:It’s just a big blob of JavaScript. It’s a single page app, and it probably deploys in about eight different files. It’s all controlled by them; we don’t have to worry about it. There’s a whole packaging process that we just run a script, and it packages it up. Then we copy it to the destination and run it from there.


Danny:It’s a crazy world we live in, these JavaScript frameworks.


Matthew:It’s nice because it does give us disconnected, we can run off of the cloud, or we can run on-premise. Then ultimately we can switch over to SQL server if we want or the customer desires, or we can still stay with SharePoint. We’ve got a lot of flexibility.


Danny:With these being JavaScript frameworks with Angular, does it matter what browser you’re running them in? Is it just a certain type of compliant browser?


Matthew:That’s a really good question because it becomes a scenario where browsers have a certain JavaScript engine built into them. Things like IE7, Internet Explorer 7, which is ancient, those tools won’t necessarily be supported.


It has to be a relatively modern browser. Even some of those require this concept called a polyfill, which is kind of a weird name. The polyfill simply means that “Look, this browser doesn’t have native capability to do this particular function X. Therefore to get it to work in your application, you need to include this special library so that when you run on this browser, it will support it.”


All we have to do is just read the documentation on the things that we’re implementing, and it will say for IE11 you might need a polyfill to support this thing that Chrome or Firefox may support right out of the box.


We just do our testing, Brandon in our QA department is good at testing the various browsers that the customer wants to run under. He just checks to make sure that it all functions correctly.


Danny:Very cool. You mentioned you’re working with Bo on this, os anyone else on the team that you’re working with right now?


Matthew:Yes. We’ve got our QA guy, Brandon is keeping an eye on us.




Matthew:He’s making things happen in that regard.


Danny:Do you have a scrum master on the project?


Matthew:Yes. Let’s see, who’s our scrum master on this one?


Danny:Is it Jim?


Matthew:I’m going to give you my projects. No, this is Rob.


Danny:It’s Rob. Excellent, excellent. I appreciate you taking the time; I know you’re busy now. I appreciate you doing this and catching up.


Love to see where we’re going with, this project’s a follow up to doing a migration and getting people up and running, is doing these little mini-applications. It’s great to see we can do them so quickly and take advantage of some technologies that are out there.


I appreciate you keeping your skills up to date and always being willing to learn new things; it’s great stuff Matthew.


Matthew:Thank you, Danny.


Danny:All right, have a wonderful day. Thank you, everybody, for listening and take care. Bye-bye.



Share and Enjoy !

Related Content: