OctoPrint Patron Survey: Results, Part 2 (Patreon)

In the second part of our survey evaluation (Part 1 can be found here) we take a look at what was the trickiest to evaluate, simply due to the volume of text: Your responses to the questions of what features you are missing in OctoPrint the most, and what annoys you the most about OctoPrint. We'll also take a look at how you update OctoPrint and what your experiences - if any - were with plugin development. 

As a quick reminder, over the course of December 2016 I did a survey among those of you pledging at $3 and up, to get an idea of how you are using OctoPrint, what kind of features you are missing and what annoys you the most about it. The goal of this survey was to get a better idea of what I should focus on during future development in order to make OctoPrint be most valuable to you.  All in all I got back 253 responses from you - I've gone through them all and extracted a ton of very helpful information out of them. 

As mentioned above the responses that took me the longest to evaluate were those about the features you miss most in OctoPrint, and the things that annoy you the most in OctoPrint. You wrote a lot there 👍 and trying to cluster everything and find common denominators took way more time than I expected when I prepared the survey. That being said, I think I managed to identify/summarize the things most of you mentioned - with a long long tail of things only one or two of you mentioned which I'll sadly not be able to get into here individually, it would simply be way too much, sorry :/

What you see up there is a representation of what I took away as the most pressing concerns for you:

• Lack of responsive modern UI: I hear you. OctoPrint's UI hasn't aged well, and grew out of a "desktop first" design approach. The necessity to  maintain backwards compatibility makes a "big bang" style replacement impossible here, but with the UiPlugins introduced in 1.3.0 it should at least now be possible to start working on an alternative without breaking things in the process. 
• More ways to customize the UI (rearranging components, more customization of individual components): A lot of you want to be able to change the order of components, manipulate the presentation of individual components and so on. A recurring theme was people wanting to merge temperature and control tab when enough space for that is available. It might thrill you to hear that reordering the tabs, sidebar and navbar entries themselves is actually already built-in - just not available through the user interface since I simply did not have time for that yet. That could be changed. I think though that trying to cram more customization options into the current UI would make it even more unwieldy - it might make more sense to rather base a future new redesign completely on the concept of customization and responsiveness.
• Better management of your "printables" (folders, adding notes and snapshots, auto deleting old files, ...): Folders have now been available since 1.3.0 went stable and should already help a lot here I hope. A lot of the other things you asked for here might need some more extension in OctoPrint to make possible through plugins - I'd rather not increase the complexity of the core file management too much, but allow plugin authors (including myself) more freedom here :)
• UI loading too slow: This is something where I'd like to ask you for some more information in the comments if this is still happening since updating to 1.3.x (where I introduced a lot of caching and other performance improvements). In my own tests against my own printing setup the web interface loads fully within 10s, with no impact on prints that are in progress.
• More flexible webcam & timelapse handling (start & stop, supported formats, ...): I hear you, and that's something already up high on my TODO list.
• Multi printer support: This is something for which we first need a new communication layer before we can even think about it. The thing is that OctoPrint's current architecture would probably not handle it well to try to keep more than one printer fed with lines to print, due to everything running on only one core and hence fighting for resources.  I've covered this a bit in the past one or two episodes of OctoPrint On Air too.
• Print queue & scheduling: An idea that I had in the past myself, I'm thrilled that you seem to agree ;)
• S3D integration: As a user of S3D myself I can totally understand your frustration about a lack of direct support in S3D for OctoPrint or vice versa. My hands here are bound however. I reached out to S3D about two years ago and offered assistance in getting a better integration going. I was asked to post this to their forums "for the community", only to see that there were already several threads asking for just this. I chimed in on all of them, again offering my help and to this day have gotten absolutely no feedback from S3D themselves. This being a closed source piece of software, there is not much I can do. Keep bugging S3D, maybe one day they'll listen, but at this point I'm starting to doubt it. In the meantime, there are some ways to have S3D automatically send sliced GCODE to your OctoPrint instance through their output pipeline settings or by using OctoPrint's watched folder, I suggest using that.
• Better GCODE viewer (3D, always available, smaller RAM footprint): Providing both a 3D viewer AND keeping the RAM footprint low and the thing generally usable on lower end clients - you are asking me to do the impossible here ;)
• Better GPIO support: In Part 1 of the evaluation we've seen how many of you run OctoPrint on a Pi or other embedded system - that's great, that's what it was designed for. That explains I guess why a lot of you also desire ready prepared ways to integrate things on your systems' GPIO pins with OctoPrint. 
• Better slicer integration: I understand where you are coming from here, but in order to do what you are asking for properly (full fledged slicing experience within OctoPrint, rivaling what you have on the desktop), I'd put OctoPrint in a situation where it would play catch-up forever with what slicing engines offer up. Additionally I'd have to find a way to provide an abstract interface to all the slicing engines that might possibly be integrated with OctoPrint, and all their settings. This simply is not feasible, it would be a project all in its own and those of you wanting OctoPrint to concentrate on being a good and extendable host first and foremost instead of trying to be a solution to the whole printing workflow would be rightfully annoyed by such a shift in focus. There is this plugin on the repository that does a lot of what most of you apparently are looking for here for cases where you absolutely DO need to do everything in the browser, and for the more regular workflow I'd rather go the other way around and hope that more slicers integrate with OctoPrint (like Slic3r and Cura 2.x with a plugin already do). To be quite honest, in hindsight I'm sometimes kicking myself for adding slicing support in the first place - from my perspective it was always intended as a quick-fire solution for STL files already oriented in the correct way, with perfectly dialed in settings, not a full replacement for the regular workflow which a lot of people perceived its intention to be.
• Additional webcams: Apparently one viewing angle isn't enough for some of you. Personally I'd rather use a filament sensor for monitoring my filament than a webcam, but your mileage may vary ;)
• Dedicated mobile/small screen UI: This is its own point because those of you voicing this wish stated you wanted a simple UI with bare necessities for mobile or other small screens, not the full fledged UI with all functionality. And once again I'm happy I added support for UIPlugins ;)
• Wifi & network management: OctoPrint is platform agnostic and an application that is not supposed to touch the underlying operating system. That being said, plugins might be possible here. Shipping something built into OctoPi that helps with Wifi setup might be possible too, but this will always be limited to a certain set of supported hardware. The Pi landscape is too fragmented and it's impossible to make a one-size-fits-all kind of solution here (that's actually what my past efforts in that direction finally succumbed to and why so far netconnectd and its companion plugin were not included in OctoPi - I simply could not make it work reliably and without potential legal implications).
• Filemanager: Check ;)
• Layer tracking ("do x at z"): This is a somewhat tricky request since if you are printing from your printer's SD there's no way to know which layer you are on, and things like "layer number X of Y" is not even possible when printing from the uploads folder. Why? OctoPrint streams the file to the printer - it reads it itself, possibly for the first time, while your print is ongoing. If you haven't had it analyse a file yet (e.g. you hit print right after upload) OctoPrint has no idea how many layers there are in your file. Things like z-hop make this even trickier.
• Issues with flaky serial connections: Flaky serial connections usually have one of these causes. If those have been ruled out, please get in touch with me through OctoPrint's bug tracker - Thanks :)
• Filament manager: Keeping track of spool inventory + filament left on the spool. I think the first time this was requested was around early 2013 and apparently demand has only increased :)
• Custom controls: I was a bit stunned at how many of you stated you were missing support for custom buttons to send GCODE macros, or fan controls, or anything else related to custom controls in general. This is a feature that OctoPrint has had since its earliest versions, and which has been made easily editable by this plugin (which somehow would make it senseless to build another editor for it within OctoPrint - maybe bundling it would make sense though). What I take away as a TODO here is a need to improve the documentation of existing functionality.
• Power toggling incl. conditions ("only when temperature below x"): This has since been added through this plugin.
• Granular permission system: A huge TODO also on my own list since a while now. Salandora actually has started working on something here, in close contact with me.
• Firmware issues in general (can't cancel heatups/homing/etc): Some of the annoyances you reported are actually things that are out of my control and a problem with how most firmware works. OctoPrint can't cancel your blocking heatup at the start of a print, or your lengthy homing routine, or your long long moves, simply because your printer doesn't allow it to. Newer versions of Marlin do have a way to interrupt blocking heat ups, but the majority of printers out there do not support that. Same for it sometimes taking a while for a cancel to go through - the only thing that OctoPrint can do here is to stop sending your firmware commands, but other than effectively nuking your firmware through an emergency stop there's no way to tell it to please stop executing the commands it already received and buffered. If you want I can further explain this in one of the future OctoPrint On Air episodes, just be aware that it might get ranty because the state of the communication "protocol" for printers is something that can really make me go up walls. Let me know in the comments if you want that or not ;)
• Controls jump on webcam load: I know, I know, I'll tackle that ASAP!
• Better user management: Some of you run OctoPrint in settings with established larger user bases. The more granular permission system is one thing that would help here to better control access. Allowing some kind of integration with existing user management systems is another part to improve experience here.

I'll match up the above against the feature requests clusters I identified in my recent spring cleaning of the bug tracker - there's a huge overlap! And then you'll get to help me decide which of those to try to schedule for the 1.4.0 release with the small caveat that some things will require some work before they can be meaningfully tackled at all.

Phew... After that huge wall of text, let's take a look at some more charts again, shall we? I also asked you about your "update behaviour":

What you reported back was a relief. I'm happy to see that most of you keep your installations up-to-date - you wouldn't believe how frustrating it is to have people report bugs you already fixed in current stable, simply because they didn't update yet. My hope back when I created the update mechanism  was that this would allow people to update in a timely manner and hence reduce the likelihood of this happening - my experiences since the release of 1.2.0 and this chart seem to confirm that theory :)

I also asked you what release channel or branch of OctoPrint you are running:

Most of you run the stable version. My guess is that those of you that still ran the Devel RCs release channel back in December have since switched back to Maintenance RCs after the release of 1.3.0, am I right in assuming that? I have to admit that I was a bit disappointed at the very small number of you running release candidates - I need feedback from on the release candidates, otherwise they won't help in ironing out any bugs I simply can't test for in my available setups before those hit everyone else. That is the whole point of putting them out in the first place after all. Anyone running the Maintenance RCs and reporting back to me if stuff works or not helps in ensuring the stable releases to be solid for everyone :)

Finally, I asked you if you ever had tried to write an OctoPrint plugin yourself  and if so what the experience was while doing that.

Ok, most of you didn't. But those of you that did found the documentation lacking especially with regards to more advanced examples and also basic things like architectural overview and such. I hear you and I'll have to look into changing that situation. Other problems you encountered while developing plugins was a lack of experience with the used techniques (Python etc) and also a generally rather steep learning curve once the tutorial was completed. My guess is that the latter could already be mitigated somewhat with some more examples. And I hope the task I still have on my agenda to create some educational videos on the matter will also help once I get around to take care of it.

This sums up all my findings from the first ever OctoPrint Patron Survey. Considering the amount of work the evaluation of that one caused (all in all we are probably talking around a work week by now), I have to admit I'm not sure I'll ever do one as large as this one again. But maybe a smaller one :)

I hope it was interesting for you as well! I for one learned a lot about your expectations towards OctoPrint, how you are using it and where I should look to improve the experience. Now I only need to find the time to tackle some of the huge TODOs you've given me with all the other stuff on my plate :) 

And last but not least - thank you for all the encouragement poured into the final "Anything else you always wanted to say" responses <3 This is now my little pick-me-up for when I feel discouraged, frustrated or outright lost during my work on this project, and it really helps - THANKS!