feat: add Plugin Wizard for guided plugin installation #2215
Conversation
|
Hmmm. Now that I think this through I don't think the "bundle" really works in all these contexts. For example when a user wants data logging they typically don't want to use multiple databases, just one. You probably don't want multiple ais forwarding methods. So these are not bundles, but functionality categories. We are also creating one more abstraction and a way to do things: bundles are totally separate from App Store categories. I think we should find away to reconcile these two:
|
|
@tkurki @dirkwa I like this design concept but does this mean that FSK, KIP, Instrument Panel, Signal K Vessel Position and the like will be removed from package.json "optionalDependencies" selection, not installed by default, and that everything will now be installable using the Wizard bundles instead? If so, how are we planning on bundling things and how will we be able to create and configure additional bundles? The reason I'm asking is some bundles are straight forward like all plugins that are Victron related, all NMEA protocols, etc...server plugins that offer unique infrastructure or core base features. Scoping bundles is way less obvious with apps like dashboard, instrument, chartplotter and similar webapps . Unless you are exploring Signal K as a new user, I don't think anyone would install all "Dashboards & Instruments" or all "chartplotter" plugins and webapps. We also need to think of webapp that have dependencies; in the case of KIP, which is just one available instrument package, it also relies on Freeboard, Polar Performance, Anchor Alarm, Signal K Auto Pilot, Signal K Racer and other plugins. We would need a KIP only bundle, a Instrument Panel only bundle, etc. In this cases we might as well keep our current plugin installation approach. In my opinion, this wizard concept is an excellent user experience, but the everything bundle maybe not so obvious to apply. I think the goal of this design is to make all the good plugins and features SK has to offer obvious to new users, right? This I completely agree with. Installing things is very easy as it is, just that unless you browse the gallery, you won't know about the good stuff. Building on this concept, what if we had a group of 2 or 3 core server plugin bundles, and another group that look like the bundles but are plugin categories instead. We need to flesh out more categories, add icons and descriptions so it's easier to explore and discover. We could also create a 'What's new since last month" using the NPM repo's "Last published" field for plugins that are not installed. We could use "Weekly download" to make a popular plugins list that are not installed, etc. - not sure what's available to use... In short, I like the design and agree with in the goal. It works well for some bundles but less so for complex web apps and groups that have many competing solutions. |
|
Thanks for the thoughtful feedback @tkurki @godind — you're raising valid concerns, and I think they point to something important: we're actually talking about two different user journeys. Journey 1: New User Onboarding (this PR)"I just installed SignalK, I have no idea what plugins exist, I want a working setup quickly" → The Plugin Wizard addresses this. It's opinionated by design. Journey 2: Informed Plugin Selection (separate effort)"I'm browsing the App Store, how do I know which plugins are good, maintained, or fit my needs?" → This is what you're both describing with categories, icons, "what's new", popularity signals, etc. I agree the bundles shouldn't become a parallel registry. But I don't think the solution is to block the wizard until we have better App Store discovery — they solve different problems. What I propose:
For the ratings system, I'm thinking something like this:
This integrates directly into the existing App Store UI — star ratings in plugin listings, comments in detail view, no separate portal needed. The enhanced App Store could eventually inform smarter bundles — but we need that metadata foundation first. @godind you're right that nobody wants to install all dashboards at once. The wizard bundles are meant as starting points, not exhaustive installs. But better App Store discovery would let users make informed choices after initial setup. Should I open a separate issue for the App Store enhancement proposal? |
|
It makes sense to me to open a separate PR for Appstore enhancements and brainstorm ideas for improvements. That said, it's if you want to eventually work on it. KIP and related features/plugins keeps me busy enough, for now. About Journey 1Then is the idea that the bundles are a limited set of core team, hand picked, bundles to add/remove on top of the base core setup? As an example; like one "Charterplotter and Instrument" bundle with say only KIP and FSK and no other instrument and chartplotter plugins. That would a good package for testing. Then one for "Automation" with Node-RED and MQTT but not Home Assistant, one for "Victron", etc. I think the challenges becomes clear when you actually list how many bundles we will have, what they contain and don't contain. If it's not a 'just to try out' restricted list of bundles, I think we will fall pray to every competing plugin and web app wanting to have its own bundle in the list to showcase their work. |
My 2c.... I also think the concept is good, and that we should first focus on first time user, first install... and I echo the suggestion of a limited set of core team crafted bundles, including a "Default / Recommended" bundle for those that do not want to make a choice. |
|
Thanks for your nice feedback. Initially I wanted for each bundle best of his class, but not knowing which it is I maybe selected too much, so for a 1st user journey a "best of is class" would the perfect fit for me. Chartplotter = FSK (incl. dependencies) what shall we pick for the others? Thanks. |
Add a setup wizard to help new users install curated plugin/webapp bundles for common use cases (plotter, dashboard, data logger, etc.). - Add bundle definitions in src/bundles/ with types and configurations - Add bundlemanager interface with REST API for wizard operations - Add Wizard UI components in admin interface - Add first-run detection on Dashboard with wizard prompt - Remove plugin/webapp optionalDependencies for minimal base install - Convert interfaces/index.js to TypeScript with ES module support The server now starts with a minimal base (only resources-provider). Users select and install bundles via the wizard or App Store.
Spinner component is not available in reactstrap 5.0.0. Use FontAwesomeIcon with faSpinner instead.
Pass empty string instead of 'latest' as version parameter to installModule. The string 'latest' is an npm tag, not a valid semver version, causing semver.valid() to return null and trigger the -1 exit code path. npm automatically installs the latest version when no version is specified. fix: wizard bundle installation failing with exit code -1 Pass empty string instead of 'latest' as version parameter to installModule. The string 'latest' is an npm tag, not a valid semver version, causing semver.valid() to return null and trigger the -1 exit code path. npm automatically installs the latest version when no version is specified.
- Allow selecting multiple bundles for installation at once - Merge packages across bundles to avoid duplicate installs - Show installed bundles with "Installed" badge and reinstall option - Simplify completion screen to restart-only with Plugin Config guidance - Rename "Setup Wizard" to "Plugin Wizard" throughout UI
Add WilhelmSK Mobile bundle for iOS/mobile app integration with push notifications and remote monitoring. Add Home Automation bundle for Node-RED, MQTT, and smart home integration. Expand Plotter bundle with additional plugins: - signalk-charts-provider-simple - signalk-anchoralarm-plugin - signalk-flags - signalk-activecaptain-resources - signalk-buddylist-plugin - @marineyachtradar/signalk-plugin Add signalk-logviewer to all bundles except minimal for consistent log viewing capability across use cases.
Add WilhelmSK Mobile bundle for iOS/mobile app integration with push notifications and remote monitoring. Add Home Automation bundle for Node-RED, MQTT, and smart home integration. Expand Plotter bundle with additional plugins: - signalk-charts-provider-simple - signalk-anchoralarm-plugin - signalk-flags - signalk-activecaptain-resources - signalk-buddylist-plugin - @marineyachtradar/signalk-plugin Add signalk-logviewer to all bundles except minimal for consistent log viewing capability across use cases.
Add new plugins to bundles: - Plotter: signalk-charts-provider-simple, signalk-pmtiles-plugin, signalk-flags, signalk-buddylist-plugin - Dashboard: bt-sensors-plugin-sk - Anchor Watch: @meri-imperiumi/signalk-autostate - Home Automation: signalk-mqtt-gw Move plugins from Data Logger to AIS bundle: - @noforeignland/signalk-to-noforeignland - signalk-saillogger - naivegpxlogger - signalk-windy - signalk-derived-data Fix non-existent package names and update test to skip when optional webapp dependencies are not installed.
Refine wizard bundles to offer curated "best of class" plugin sets: - Reduce to 6 focused bundles: Administration, Plotter & Navigation, Dashboard & Instruments, NMEA Integration, Bluetooth Sensors, WilhelmSK - Add chart providers to plotter bundle (charts-plugin, pmtiles-plugin) - Remove vesselpositions from plotter (not essential for navigation) Fix installed bundle detection: - Use npm package names instead of plugin IDs for comparison - Handle bundles with only optional plugins (check if any installed) Simplify plugin_wizard.md documentation to avoid drift from implementation. Use faTowerBroadcast icon for Bluetooth bundle (faBluetooth requires brands package dependency).
dirkwa
force-pushed
the
setup_wizard_and_bundles
branch
from
a02c30e to
15afcac
Compare
I have rebased this PR to the latest master and massively reduced the bundle offering. Hope this will allow new users a easy and quick onboarding for Journey 1. None of this bundles or plugin selections are carved in stone, they can be adjusted in |
|
Just thinking back to when I first discovered Signal K (which was v0.9 so quite early), after I installed it there wasn't much I could do (even though Freeboard was there to use you could not create resources, etc) as I was at home and had no access to any meaningful input. So it would be nice, I think, to deliver a "package" to at least let you tryout the apps that are installed. The options for that today are:
A simple way of providing a data stream would help the "tyre kickers" to at least see what SignalK can do. Thoughts? |
@panaaj @godind If we want to reach a broader audience I would suggest a Youtube channel showing the latest upgrades, inventions. In case we want to reach JOE BOATER I can ask our friends like Bryan from Delos or Warren from WEsail, etc. This should be covered by various press releases and featured articles in the major magazines. So that SK gets the new "hot chick" in town. I can't wait for this but we'll need to finish some homework first. Radar support f.e. is one of the major missing items imho. No worries, we'll get there. Instead of messing up the customer install and if someone is willing to maintain it I would recommend we have it as a Demo Container in the Universal Installer I am currently working on. Here we can easily pull a pre configured demo container from the registry and will be back to production within 2 seconds. |
|
I completely agree that having simulated or streamed data files is critical to getting newcomers onboard quickly. Without this, it can take a lot of time and energy for users to understand how things fit together and to actually see plugins and web apps in action. A well-designed stream file could go a long way toward solving this—much like what’s available at demo.signalk.org. This could even be offered as a standalone bundle. One challenge I see is that most plugins require environment-specific configuration before they do anything meaningful. That raises an important question: does it make sense to install plugins that newcomers can’t experience right away? In that case, they risk feeling more like bloatware than value. Bundle ideas
What about merging the Plotter and Dashboards bundles into a single offering? We could position it as:
To really bring this to life, I think we need a way to script deployment configurations—for example, deploying a special bundle with a predefined KIP layout that actively uses plugins like anchor, tides, etc., along with FSK maps, waypoints, and routes that are compatible with the stream file. Hopefully that illustrates the point. These are just some thoughts. As mentioned before, once you get into the details of “ready-to-use” installation bundles, the number of truly useful combinations is fairly limited. Unless the goal is simply to preinstall plugins that don’t do much out of the box—which may not be ideal. In that case, it might be better to let users start small and build gradually, while offering videos or demos that showcase what’s possible. |
|
The more I think about auto-bundling, the more I come back to thinking improvements to the Appstore discovery will ultimately bring more value. Plus as you said @dirkwa, a Demo Container or some well integrated demo deployment package is an unbeatable approach for newbies discovering, like at trade shows. |
|
The biggest problem is that we are already too product bind imho. We are mixing 3 different path:
All of them have valid pros and cons. I say:Let us start with Journey 1 - this is already a major improvement over what we have today for new users I promise:I will do a PR for Journey 2. Demo Container:If you agree on a maintainer I will add this to the Universal Installer. Sounds good? |
|
I think this reflection has led me to the conclusion that, personally, I would drop Journey 1 and instead reuse its concept for Journey 2. In my view, this offers a higher value per line of code to maintain in the future. That’s just one opinion among others, and ultimately I’m confident the result will look good regardless. I’ll adjust KIP and/or its packaging as needed to align with the PR.👍 |
|
Just to wrap up.... I don't feel that strongly about one option over another, just that it adds value to the targeted user group. So to summarise my thoughts:
|
|
Just tried this & tried to wrap my head around the idea. I find the idea of a setup wizard good, but the approach based on bundles is imho wrong. All of the example bundles include some plugins that are relevant, but also some that aren't. I don't want people having maretron plugin adding confusion, when they have no maretron equipment. If your friend had a boat, they had installed a barebones SK server and asked you to help add useful or even required ones how would you about it? What I would do is that I would first ask
To pick one example I don't think there should be an NMEA bundle, but if there is already configured or user indicates NMEA2000 then visualizer, sk-to-n2k and n2kais plugins are relevant. And if the user answers Likewise Imho this would be more user-oriented and would also help the user discover the differen possibilities. |
|
This PR is also "sneaking" in a new concept, Landing Page. A valuable idea that has cropped up before, but mostly independent from the wizard. I'd like to handle that separately, as we need to come up with a good solution. |
|
The current approach is already shrink down, so just a few apps, that a very useful for a new user are installed. I highly recommend you review your decision. It was clear for me that Adrian and David will speak up as they will loose their prime position, although even today it is not done correctly and all the recommended plugins that FSK needs to properly work are not installed - what a end user experience. Why do we need to clutter the Webapps with stuff the users do not want and can not really uninstall without them respawning at the next upgrade? For me the bundles are "best of" and will be reviewed based upon stats from a improved App Store.What will we make a impression for new developers or corporations if we always push the own plugins first? Maybe in 2 yrs there is a EMPIR-BUS or MARETRON dashboard or a AI-POLTTER from Startup XYZ. I see @sbender9 's WilhemSK f.e. as the 1st "industry" customer. He offers a solid product offering for mobile devices. IMHO - If we want to grow SignalK we need to make the right strategic decision.a) We are a OPEN platform that recommends upon usage and user rankings b) We are CLOSED shop and push our own plugins regardless what the users want and show the industry that a investment into SignalK is useless. My vote is for A - and only A. Thanks. PS: Your argumentation and answer showed me that you haven't looked at my last Commit, maybe it's worth the 2min. |
Public and Official Clarification:I would like to make it absolutely clear that I never intended to criticize either of you personally, nor your wonderful contributions to SignalK in any way. On the contrary, what both of you have achieved was the very reason why I became interested in SignalK and your plugins in the first place. As you may have seen from my previous issues, I am actively working on—and dreaming of—replacing TimeZero Pro with FSK and Maretron N2KView with KIP. If my comments gave a different impression, then I sincerely apologize to both of you, publicly and wholeheartedly. My intentions in this matter are solely focused on the end user and on helping SignalK become a “must-have” application that also appeals commercially. I believe that we collectively benefit if, for example, Raymarine offered Lighthouse charts as a paid plugin, or if manufacturer XYZ decided to build a SignalK-compatible radar, or company ABC provided 4.1" SignalK displays similar to the Raymarine i70, or autopilot control heads comparable to the p70—just as an example. In the current implementation I see almost no difference compared to a built-in feature—the user makes a few clicks and it just works → great user experience. Speaking as someone who ran a successful software and content business for many years, I would never have approved a budget if I had felt like the “third wheel” in the process. However, when conditions are clear and there is a visible market—ideally with first-mover potential—we acted quickly and effectively. That’s how we grew our company. This is why I advocate and push so strongly for keeping things open. I hope my thoughts are clearer now. Regardless, I would again like to offer my sincere apologies. |
|
Apology accepted. I’m not seeking favors with KIP. I’m genuinely trying to integrate with FSK and other applications around a solution that could eventually become a strong alternative to high-end commercial offerings. If we move underlying pieces around, I want to understand how to keep this vision alive and, most importantly, very accessible to newcomers. Because we’re talking about changing how contributors’ work is showcased and deployed, I’m sharing my experience from helping hundreds of users configure dashboards and instrumentation. With some luck and a lot of hard work, I hope this experience can help make that goal a little easier to achieve. I don’t see how SK is not open. Can you share an example? It’s also important to recognize that once we introduce the “commercial” or “money” angle, it becomes an entirely different conversation. Finally, I want to say that I have no issues with disagreements — even those that don’t resolve themselves. That’s healthy. SK has come a long way, and I trust the people who have brought it this far. |
If we favor FSK and KIP not upon user ratings (Journey 2) and bring it always build-in than I doubt we spent a lot of effort to leave the framing "Data HUB" and will be seen as "Open Source MFD" fighting against OpenCPN. It would be a waste. Signal K has way more potential than only this. There is no need to do so and with the bundles here proposed KIP and FSK are part of the new user Journey 1. |
Feedback on Plugin Wizard PRFirst, I want to sincerely apologize for the oversight of not pulling the latest branch before providing my previous feedback. I inadvertently spent time commenting on a stale version of the code, and I appreciate your patience while I get back up to speed with the current state of the PR. Regarding the core concept: implementing a wizard to assist users in navigating the "what plugins do I actually need?" hurdle is an excellent and highly valuable idea. We all know that the initial setup can be daunting for newcomers, and a guided experience is exactly what the platform needs. However, I believe we still face a fundamental architectural problem: we currently lack a library of well-defined, genuinely useful plugin bundles. The "Goldilocks" Problem with BundlingWe seem to be swinging between two extremes without hitting the sweet spot:
When the UI tells a user to "Choose from curated bundles tailored to your needs," it feels like we are overpromising and underdelivering. A bundle of one isn't really a bundle; it's just a recommendation, and the current selection doesn't yet live up to the "tailored" marketing. Aligning on GoalsTo quote David’s perspective, which I find very grounding:
I am 100% aligned with this goal. The disagreement isn't about whether we should help the user, but how we categorize that help. A Needs-Based Approach@dirkwa @adrianp @godind, I’d love to get your deeper thoughts on the scenario I proposed earlier:
To use a specific example: I don’t believe a generic "NMEA Bundle" is the right approach. Instead, if a user indicates they have an NMEA 2000 network, then—and only then—do plugins like the Visual Visualizer, sk-to-n2k, and n2k-ais become relevant and helpful. Starting from the user’s actual needs and hardware constraints is what will truly help them take those successful first steps. While I recognize that data connection configuration is the true first step, focusing on a needs-based plugin wizard is a great place for us to start. Moving Forward@dirkwa, you have been a strong advocate for this PR, bringing up various arguments—everything from how we promote Signal K globally to "keeping Signal K open" (I found that particularly odd...). While I think we are actually very well aligned on those high-level philosophical goals, I have to ask: Why is it so vital to merge this specific PR in its current state? To me, this currently feels like a great "Proof of Concept" or a demo of a feature, but I don't feel it is production-ready. We have a solid UI foundation here, but I believe we can develop this further to ensure it truly serves the user in a meaningful way before we commit it to the main branch. |
|
I really appreciate that we're aligned on the core idea. That feels like the important part. You're right that the current bundles are thin — I won't argue with that. They reflect what we have today, not where we want to be. I think of this PR more as laying the groundwork: the UI, the flow, the infrastructure. The bundle content itself? That's where I'd love us to iterate together once we have real user feedback. A few things I'd be open to:
As for journey 2 — the needs-based approach you described — I'm genuinely excited about that direction. I'd be happy to open an RFC or issue for it once this lands, so we have a concrete next step rather than just a vague promise. The demo/show-off piece came up on Discord already, so that's being tracked separately. What do you think — does this address your concerns enough to move forward? |
Amen to that—I can’t think of a better way to propose a well-tailored, genuinely useful plugin set. What if the UI asked those exact questions, allowed the user to answer them in a single AI prompt, and then:
That kind of guided, intent-driven onboarding could dramatically lower the barrier to entry while still respecting Signal K’s flexibility and power. It would be a very cool AI project. |
|
Clarifications on the idea to use AI:
|
|
Some AI supported wizard concept generated by ChatGPT |
4 participants
Summary
This PR introduces a new Plugin Wizard that guides new users through installing curated bundles of plugins based on their use case. Instead of manually searching through hundreds of plugins, users can select bundles like "Plotter & Navigation" or "Dashboard & Instruments" and get a working setup quickly. I've done my best to include the most useful and well-maintained plugins in each bundle. If I've overlooked any plugin, I sincerely apologize - every plugin author has put significant effort into their work, and any omission was not intentional. Please let me know and we can add it in a follow-up PR.
Features
Bundles include plugins for
Technical changes
src/bundles/module with bundle definitions and typessrc/interfaces/bundlemanager.tsfor installation logicpackages/server-admin-ui/src/views/Wizard/Future work
Two providers (
@signalk/resources-providerand@signalk/course-provider) are still included by default in the minimal setup. These could be refined in a later PR based on user feedback.Sample UI
Dashboard when no plugins installed:
Welcome message when no plugins installed:
Bundle selection
Confirm installation
Install with progress bar
Installation Complete