Now if you are just talking about an Application.cpp/ino (aka sketch), that is actually Spark FIRMWARE, whether you code it locally or in the Sparkulator (web IDE), it’s still Firmware.
That should cover things pretty well, and then for the bits that don’t fit into either of those… there’s the General category
The thinking is, appears to be, if you can tell, drop it in General where it will only take about a month for someone to find. I wonder how long ebay would be in operation if they only had a dozen main categories and that was all ?
Hey @spydrop , there’s no reason to get snarky… if you think General is too lame… continue the discussion and offer some solutions. I don’t make the rules or anything, I was just stating the way it’s currently laid out.
What’s your definition of Non-Official Non-Cloud Base? That doesn’t sound like something that interfaces to the Spark API. Perhaps Cloud Software should be renamed to just Software, but then that could be confused with Firmware too easily I think.
I suppose it could be called API Interfacing but then it’s not hip anymore with the word Cloud. Cloud doesn’t have to mean it’s IN the cloud… just that it’s communicating with the Cloud aka Spark API / Spark Server.
Maybe I’m interpreting things wrongly.
Technically Discourse allows you to create Child categories… so we could offer some clarity in the Cloud Software category with different types of Cloud Software… and make them all the same color as the Cloud Software tag.
This could be helpful to sort things better. Discourse does kind of get hard to search for things when there are tons of posts. I have trouble finding my own posts sometimes.
And someone else besides me just happens to mention a change would be in order and you want to throw it on my back. I offered a few options but regardless, there is a real need to separate Cloud from other user interfaces so people who are not programmer do not just go back to using a much more accessable Arduino. Not my decision either.
You are continuing to suggest Spark will be out of business soon if they don’t add some more categories. Am I interpreting you correctly?
You can call something an Android App all day long, and someone can still fail to see how it communicates to the Spark API. People will have to learn through good Spark documentation, and clearly documented user examples. Trying to stuff all of the documentation into Category descriptions doesn’t seem like a solution. I also don’t see how categories will make or break Spark’s future, but it’s a possibility to add more categories. It’s pretty easy to do as well. The question becomes, does it start to clutter up the forum in any way or does it make sense?
I’ll wait and see what others have to say before I comment further.
Just wanted to chime in and let you know that this discussion is something on-going internally @spark, and we’re very much strategizing the best method(s) for organizing and presenting Community Content. Keep the suggestions coming, this is of course extremely useful feedback. Really appreciate it!
I see where you are coming from and that’s not going to work for everyone.
How about controlling the Core pins High & Low from an IP address and all the needed code (including access token) are 100% “ON THE CORE”. No need to read Squat. Just flash the “TWINKER CODE” (As I call it) and control a spark core project in 30 seconds from a Local IP using your Tiny Webserver and not having to read 15 pages of docs, etc.
I will post the final code at Github next week as I still need to finish the external css control.
Sure, I may not be a programmer but, I can kick that official box so hard that eventually it lays down and gives up
How would that not work for everyone? It’s open ended… the limit to what a new user can discover and learn about the Spark Core only ends with the Internet shutting off. You yourself have learned everything you know about the Spark Core through all of the same documentation, google and asking of questions and looking at user code that everyone else has access to. And now you are proposing to post the culmination of your journey as a finished project that someone can get all of that information in one place from.
So you really just want a special category for your project to allow users to find it easier? There is the Project Share for that. If you go so far as describing how someone else can implement your project step by step, you should call it a Tutorial, which is a child category for Project Share. Effectively it will be displayed as “Project Share / Tutorial”. I would suggest adding a proper Title to the post that includes intuitive keywords.
Perhaps in the future we will have more subcategories or a tagging feature to help augment your post.
Well, one thing we can all agree on is this: It is helpful if topics are correctly categorised. When one starts a new topic one is prompted to choose a category. At THAT point it would be helpful if the dropdown list had the one liner summary of the category’s purpose.