In the world of Tabletop Role playing Games (TTRPG’s), improvisational skills are highly valuable and not something every Dungeon Master (DM) has, especially not beginner DM’s. That’s why I came up with foreverDM, to help keep games moving when the DM is at a loss for words. My (now) husband and I ran into this problem a lot while starting out TTRPG DM journey: sessions taking a strange turn that wasn’t prepared for initially and that one now has to scramble to fill in the details for.
Outline
I wanted to create a Discord bot to provide answers to improvisational questions asked of it based on the information stored in the bot. It also needed to be accessible to anyone with a Discord account and an API key, as that’s where a lot of people play their games. So I couldn’t make a bespoke application, nor could it be too expensive or slow to run with too many inference calls. It had to be able to run within the space of a D&D turn. The Discord API was surprisingly simple to use after some research, but customer interviews revealed that answering improvisational questions was an area of TTRPG’s that the target end user preferred to do on their own rather than rely on an LLM (large language model).
Pivot
With that last realization, I had to come to terms with my product: should I continue on the assumption that TTRPG players wanted help with improv, or pause development in consideration of what the end user actually wanted? This was a hard choice, as I was really excited about foreverDM being helpful to people, especially beginners. However, I ultimately decided to shut down the service, as the claim had proven true. The bot just wasn’t being used, and it made no sense to continue development or service.
The Outcome
Shown above is the first and only version of the foreverDM website, where you could invite the bot to your server. It was based on the RWKV v2 model, an RNN style of large language model that would run locally on my laptop’s hardware. As mentioned above, the bot wasn’t being used, revealing that I had misunderstood the needs of the end user when conceptualizing the product to begin with.
Retrospective
ForeverDM has been sunsetted, but i learned a lot from it. In future projects, I aim to do more customer research before even starting building, so that I have a careful understanding of the issues my target customers face. In addition, I would like to sharpen my marketing skills in the way that I position my products so that they are genuinely solve the end user’s problem without relying on initial assumptions.
The Problem
My husband and I also love to write stories together. We dream of entire worlds, filled with characters and unique magic systems… and many times they stay dreams because neither of us writes them down. It doesn’t help that most messaging apps, where many a collaborative plan is made, are difficult to search through. In fact, it’s a common complaint that they have this detriment, causing many a plan to have been lost to the chaos of last week’s messages. So I decided to do something about it.
Outline
Xandria is a local-first application hat turns chat conversations into readable wikis. It’s entirely my own project, from concept to where it is today. I wanted to design an application that was local first and self-host-able. Private conversations and plans would be had in this application, and there was no sense shipping that data off to an impartial party. I also wanted to target an M4 Macbook air as the minimum software that could run the application, making it useful to writers and students alike, who would likely make up the planned self hosted tier.
Pivot
To understand this research, I drew on what I had done in a previous project: foreverDM. I tested various local AI models against the way my application transforms input messages, created a functional prototype, and rehashed how I could build an even better version. That second iteration was a huge fork in the road in the development. I originally started the application as an electron app, which did work, but consumed a lot of resources and was a hodgepodge of initial attempts. Now that I had gotten those attempts out of the way, I decided to rewrite the project to be smaller in its infrastructure, better integrated in its safety, and easier to understand.
The Outcome
I am still developing the second iteration of this project. So far, I have built a platform that takes chat messages as an input, and produces a human readable wiki page that summarizes the conversation in accordance with the selected topic. It has a text transformation pipeline that uses both deterministic and heuristic evaluation methods to produce the wiki, complete with a user attribution system that tracks version histories. The rewrite was the right decision to make, as the current alpha is under development and already has marked improvements in its setup flow and wiki outputs compared to the first iteration.
Retrospective
As of writing this case study, we are still testing and in alpha. Product demos will be posted once the text output system is finalized.
The Problem
Morganics Handcrafted had a problem: it was taking them hours to add supplier stock to their Shopify storefront, which ate into their production time. They needed a solution that was specific for their supplier and easy to integrate. I was commissioned to solve this problem for them, and I owned the implementation from solution to end product.
Outline
My solution had to be easy to adjust and integrate as well as use. I had to balance customer demands with what the supplier’s and Shopify’s respective API’s would allow me to know and do, all within about a month or two before a large order was to arrive. So, I got to work researching the Shopify and supplier API’s. Shopify, I found, was incredibly flexible in the internal and external tools it could support. The supplier’s API was less flexible in the information it provided.
Pivot
Initially I misunderstood that the customer wanted to search for an item, which the supplier’s API did not support. After clarifying with the customer their intent and goal, I discovered that they expected to have a SKU number with them when adding items to their store, which was something the supplier’s API did support searching. From there, the work was far easier to implement at no extra cost.
The Outcome
In the end, I produced a Shopify plugin that satisfied the client’s goals and then some. The client was able to input a supplier SKU number, select all matching products, and the plugin would pull their official name, description, photos, and SKUs, calculate the ideal price, and put that as a draft product in their Shopify store, all with one click. The client also had the option to name their own price for a product, should they not like the price calculated based on rules they themselves had set.
Retrospective
The client was incredibly impressed and found the plugin easy to use. It took the task from taking hours down to just minutes, making batching simpler and saving the company time and money. If I had the chance to do it over again, I would have established the customer’s inputs from the jump. That would’ve saved me time and energy, and produced a more cohesive product. Future iterations on this project could include more emphasis on the UI (the improved mockup shown above), but given my rushed timeline, a better UI was not finished.
The Problem
Being a division focused on ground vehicles, the Westford DCS, the client, did not have the ability to produce effective internal UI’s for the testing software project I was assigned to. Fortunately, I have a degree of design sensibilities and enjoy UI projects, so I was up for the task. I was in charge of the project’s internal UI, particularly the testing engineer’s view. I had near free reign to develop a C-compatible user interface that could read and give ques to the rest of the program. I was given a few mockups made in Tknter, a Python UI library, as an example to start with.
Outline
The issue with the UI for this project was that it was far too complicated for what it needed to do. It had been a victim of scope creep, gradually gaining new features that would only be useful to the lead designer rather than the testing engineer who would use the interface. I discussed the UI with these test engineers who confirmed the problem, and gave me an idea of what sort of interface they were looking for.
Constraints
The constraints the project had and that the test engineers laid out were as follows: The product had to be incredibly simple, with a big, easy-to-see and -press button in the middle. It needed a place to display logs, a place to load testing profiles, a way to read recently emitted logs, and a way to tell if the application was still running while looking idle. Lastly, and I put this constraint on myself, it also had to look good to anyone who saw it.
Pivot
I confered with the end users of this interface several times throughout the project. I was surprised by how little information they wanted in the end, and had to think about how to hide what wasn’t needed, but still make it available in case it was. I decided to keep the design of the UI as minimal as possible while utilizing animations to cleverly hide unnecessary information. Rather than have the log side panel openly available from the jump, it’s hidden behind a button that expands when activated. All other logging information: the status of various features being tested, etc. was not needed and therefore cut from the simplified screen. I built the tool in Rive rather than Tkinter to accomodate the animation and buttons I’d need to make the user interface a polished experience.
The Outcome
What was left was a giant button, a heartbeat monitor, a file selector button, a bar for the file selected, and a bar for the most recent log. The button changed from red to green and back again when text, alongside “START” and “STOP” text as appropriate in a graceful animation, and the log window slides in and out of view at the click of a button. The supervisor who assigned me this project was impressed, as were the end users who would be using it. The interface was easily controllable in C, and simple enough for the end users to immediately know how to use the software. Future iterations could have an additional engineer’s view with more detailed information. Due to time constraints on the project though, I was unable to add this view, but what I made is available by clicking the above image.
The Problem
DCS had created a really cool e-textile cable with applications in the military support industry. However, these cables could not be validated in their electrical abilities ahead of time, causing iterations to be costly and hard to predict. I, having experience in the e-textiles field, was tasked to help remedy this. I was to develop a software that would simulate the electrical properties of the DCS e-textile cable and predict its ability to communicate over certain protocols. I owned this entire project, save for some assistance in testing the product in a lab, and project management. This project is on its second iteration.
Outline
The first iteration of this project that I did, which I also owned and developed, was successful in proof of concept. This iteration was created using to free or cheap software as a proof of concept. The second iteration had a larger budget, and the goal was to be able to predict what communication frequencies could be used over the cable. The client expected to be able to design their own e-textile cable and submit it for simulation, meaning that I would need to be able to systematically generate heavily user-customized 3D models to then simulate with. Meanwhile, the simulation software I chose would need to be able to simulate the electrical property that mattered for said customized cable, and represent this visually in 2D and 3D views as well as back up its results with additional data and graphs. The project was scheduled for 12 months, but was cut short to 8 months due to budget constraints.
Pivot
To understand this problem better, I had to become proficient in CST Studio Suite as well as leverage my expertise in Blender, Rhinoceros 8, and Python. I was impressed by how script-able these software were, and used that to my advantage when pulling together this project. The project, halfway through its development, ran into issues with its models not producing expected results over the course of hours, and sometimes days long simulation runs. This put the project in a make-or-break state that needed to be solved quickly. After some investigation, I discovered that the first version of the cable generation pipeline needed to be redone almost entirely, as a prototype component for initial validation was causing a bottleneck in the simulation software, producing unexpected results. I was able to redesign the pipeline with this information in mind, which almost immediately resolved the problem.
The Outcome
In the end, I developed a complicated piece of software that I’m rather proud of. It starts in a specialized port of Blender that generates an editable DCS E-textile cable 3D model. The end user is able to lay out the traces they prefer in a cable and design parameters in a way they see fit. From there, the software is transferred into Rhinoceros 8, where the user identifies the different materials used in the cable, while the software transforms the mesh model into a NURBS object with materials that the simulation software can read. After this process, CST Studio Suite is opened and a simulation is run, measuring the cable’s ability to communicate in various circumstances. From there, results are viewable in 2D and 3D environments, supported by graphs measuring various properties at different points within the cable.
Retrospective
The project has since been greenlit for the next phase, with goals of turning it into a product for distribution within other government agencies. This project has directly made a mark to several partner organizations as well, including picking up the interest of the Advanced Functional Fabrics (AFFOA) organisation. Future iterations will include the ability to swap connectors and produce weaving diagrams for production, among several other client requested additions.
