What’s The Point?
I suppose it makes sense to first start out by explaining why I’m building ProffieConfig, what goals I have with it, and how that’s influenced things.
The Proffie “Problem”
Proffie has a reputation throughout the saber space as being difficult because you have to “know how to program to do anything,” and while that statement is disingenuous at best, it’s certainly not the easiest to get started. IMO a lot of that stems from a couple of things: a steep learning curve at the front of getting into things and a lot of lacking understanding around what’s possible and how to use things going forward once you’ve figured out your first config and upload.
The former makes sense, gathering Arduino, a text editor that doesn’t suck, installing drivers (especially when there’s something like Guillemot’s stuff in the way), even things some of us would consider simple like downloading ProffieOS and opening it in Arduino, opening their config, and making sure that they’re actually editing the right config, are all things I see firsthand people new to proffie struggle with for one reason or another.
ProffieConfig V1
This is where ProffieConfig V1 really started, its goal was to have a setup and UI that got users through the door quickly. By making ProffieConfig a single thing that was downloaded, where they could pop in their old config and just go, it got a lot of people off the ground a lot faster than they could have otherwise, some people even decided they wanted to try out using Arduino afterwards, and because of having already seen the fundamentals of things with ProffieConfig, that was a bit easier for them to grasp.
Additionally, and to the second point of difficultly, just being able to see all the options laid out concisely has been helpful to a lot of people. I’ve had cases where people who have used and are quite familiar with proffie surprised when using ProffieConfig cause they saw an option that they thought was cool and they hadn’t seen yet. There’s very little in ProffieConfigV1 which is not well documented on the POD, but even still being able to visually see things laid out plainly helps expose people to what’s possible.
This is not to say the pod is bad or not doing its job, to be clear. It’s an invaluable resource without a doubt, and the detailed and comprehensive explanations of different concepts is absolutely necessary. What I mean to point out with the aforementioned is a simple, hard truth… unless people have a reason, they often won’t read the documentation, and providing an overview of things to, once again, get people “in the door” and curious about a particular feature(s) is something that I hadn’t thought about when initially developing ProffieConfig V1, but has been an interesting advantage nonetheless.
Inexperience —> Convolution
ProffieConfig v1.6, the most recent major version of ProffieConfig, and the first version that really started expanding what ProffieConfig can do, was when I started thinking about a rewrite.
Iirc it was v1.6 that introduced the ability to edit and manage multiple configs, added in a main “landing page” menu to the app, among other smaller changes. This was a huge update. Before that ProffieConfig was just a config editor, really. As soon as you launched it, there was the editor. You could load up new configurations and export them out, (and upload of course) but that was pretty much it.
Because of this v1.6 basically worked backwards, trying to move what used to be “The App” (the editor) into a separate, handleable thing. With ProffieConfig being my first proper desktop app project, and me being relatively new to C++ in general, there were a lot of bad things I did when writing it, and as I looked at the work I had to do for v1.6 along with the features I wanted to add, it made more sense to rewrite things differently.
Things I wanted like:
- Better handling of bladestyles
- Better management of configurations
- Better isolation of features to make development easier
- Better, more reliable handling of the upload process as a whole
- A presentation of features that went beyond “here’s a bunch of options on a screen”
- Better blade array handling
- Better config parsing (there were many unique configs that would trip up ProffieConfig V1)
- Easy updates for the end user
- General polish
- A better project management/build system (I was using
qmakeand QtCreator at the time… despite being written using wxWidgets) - Many little things
- My sanity I’m mostly joking
What ProffieConfigV2 Wants To Do Better
Besides a lot of architectural improvements along the way, ProffieConfigV2 wants to lead on from where V1 left off… if ProffieConfigV1 got people in the door, ProffieConfigV2 wants to repaint the house.
“Global” settings and human-centered configuration are really two key ideas ProffieConfigV2 features are being built around… but those are basically buzzwords and meaningless, so here’s what I mean practically.
The ProffieConfigV1 introduction was significant development-wise because it showed me how to create interactive experiences like that. Some people found it very useful, some people were confused by it (not understanding why certain things were locked off to them and that they were being guided), and some people just plain skipped it. The idea of introducing a user to the configuration process is perhaps one of the largest challenges… text-based or w/ ProffieConfig. While the Introduction was the first attempt at doing that, I think I can do better, and I think there’s a better way to go about things.
@profezzorn has (I don’t remember if it was in PMs or in a public topic) talked to me about what he considers good UI. It’s an idea of being plainly easy to grasp, guides the user by its nature and makes it clear where they should go, and yet still allows for advanced features the more and more familiar users get with it. And it’s with this idea I began my notes about how to build ProffieConfig V2
There will be no introduction.
…well that’s sad–because the entire configuration creation experience will be interactive.
Whenever creating a new configuration, instead of just dropping a new user (or even an experienced one) into a blank editor, ProffieConfig V2 will guide through the process. Instead of showing a user a hypothetical config during the introduction, it’ll guide a user through making their actual config.
But wait, that’ll be annoying to repeat users!
Not if the basis of the walkthrough is natural and the extra on top is purely informational.
But how will it be “natural,” what does that even mean?
Well, here’s where the radical difference between V1 and V2 begins. I start explaining things with this example because it’s both the first thing a new user will probably do, and a core part of the experience that highlights well my goals:
The Human Condition
Saber’s aren’t put together by clicking buttons or writing code, not physically at least. The very first thing that happens in a saber’s life is to have a design dreamed up, manufactured, and then meticulously (sometimes less so, but that doesn’t sound as fancy for this little bit) assembled by an installer.
Thus when creating a new config a user configures all the wiring-based aspects of the saber by using what I’ve liked to call, when talking to people thus far, KiCAD Lite 
. Put simply, users create a schematic in order to configure blades, buttons, things like RFID modules, etc. How this whole system works is for another later post, but that idea alone should put into perspective how ProffieConfigV2 is going to be laid out.
I’ve focused heavily on “what makes sense in the context of creating a saber and how it’s used?” instead of “how does the ProffieOS config file do it?” It’s a stark difference in practice/implementation, but I think it better aligns with ProffieConfig’s goals to be human-centered and make as most common sense as possible.
In the next post I think I’ll talk about development as it started, going over the first key things I tackled, and going from there how these different features have been implemented, or at the very least the groundwork for them has been laid.