Hello fellow Playgrounders!


INTRO
I love D&D 5e and after hanging out on the forums for a few years I noticed people frequently complained of 5e's lack of tables and set DCs. I had mostly accepted this as truth, until I read a post on this forum which convinced that me it may be worthwhile to re-evaluate my opinion.

So I dug through all the 5e books that I own and started recording every table and rule that I thought I would want on hand as a DM, which book it was in, what page it was on, etc... It turned into kind of a digital DM Screen spreadsheet.

Not being one to take the shortest path, I decided to take all this data and turn it into a web app. And so the 5e SuperIndex was born.

I wanted to start up this thread for two reasons: the first being to answer any technical questions people have about the app and its development process. I've seen a lot of interest in web development on the Playground and while this is pretty far from an enterprise level application, there was a healthy amount of good design principles and methodology that went into designing the app, the workflow for development, and my deployment procedure. The second reason is that I want everyone to know that they, too, can build the tools they want, even if starting with next to no experience. 90% of good tool design is research and knowing your audience; coding skill is secondary.

The First Deployment

My first cut of the app was deployed one week ago. It was a labor of love and sweat born over the weekend. Ironically (or maybe just coincidentally) I did most of the data entry between my turns while playing D&D on roll 20. The app looked like this.
Spoiler: Original Deployment
Show




At this stage, I considered it to be more a proof of concept than a minimum viable product. Still, eager to improve, I sought out feedback for the D&D community and was not disappointed with the response.

Iteration and Improvement

After collecting over 30 responses from users across various mediums, I developed a list of features, improvements, and bug fixes that needed to be implemented in time for the next patch (the one that I would push a week later, today).

While gathering this feedback and interacting with users, I did 3 things which are fairly typical in a good development process:
1 - I researched good UI design for the type of data that I was working with. I also knew that the color scheme of the app had to change, so I did some research into good UI design practices for color palettes.
2 - I prototyped the new UI. If this had been a professional project I would have used tools to do this, but it was my project and I'm old school, so I drew my prototype on paper.
3 - Used google analytics to track user data and draw valuable insights into usage behavior for the application.

At the end of it, before I started work on the first major update I had, 1) A well definied scope (list of features, bug fixes, and improvements) 2) A UI prototype to build towards 3) Multiple color palettes to test. In addition, I had learned when users wanted to access the application, where they came from, and most importantly, which platforms they were using to access the application.

The last one is particularly important because about an even 50% of users were accessing the tool from mobile, making mobile the largest platform for my users with desktop (45%) and tablets (5%) following behind. In other words, my design would have to take a mobile first approach (or "responsive" approach if that word means anything anymore) because to do otherwise would alienate the majority of users.

So in addition to a workflow for data entry, a workflow for development, and a workflow for deployment, I also created a testing workflow so that I could test the app on mobile prior to deployment. The creation of so many workflows may sound arduous, but each workflow was created out of a series of methods designed to save me time and improve quality and without such well-defined workflows I would have easily tripled my time investment on the project.

The Results

Most of a battle is preparation, so by the time the weekend rolled around and it was time to do the coding, it all flowed very naturally and quickly.

Here's the results (sorry the image is so tiny):
Spoiler: After the Update
Show


And here is a side-by-side comparison:
Spoiler: Before and After
Show


Needless to say I'm already gathering more user feedback for the next major update (due out in April).

Conclusion
I do not consider myself a javascript developer. In fact, javascript is one of my weakest languages. That said, a series of logical, researched methods (workflows) can go a long way towards making up for a lack of skill.

I feel that this post is getting a little verbose, so I'm going to end here. But if you have any questions about literally *any* part of the process I'd be happy to answer.

And if you have an idea for something you'd like to build but aren't quite sure you're ready to do it yet, I hope that this helps you to find the courage to take the first step. The more people we have making wonderful tools and apps for the community, the better and stronger the community will be.