Because Local Building applies to both Spark Core Firmware local building and Android App local building I would like to suggest a new Category for the Spark Community Forum:
— User Interfaces
OR
— Applications
A lot of times peole do not clearify which is done for the two different modes: Firmware / Applications
I’m not sure I understand what User Interfaces has to do with local builds?
Is the Spark API Android App not a User Interface ? That is built localling ?
Is the Spark Firmware not built Locally as well.
Doing a search here for local build brings up both Eclips App Local Builds & Spark Core Firmware Local Builds.
I think we need a category to just help separate the two process. One being Local Build of Spark Core Firmware and Local Build of Spark Core API App; a User Interface
I think the Cloud Software category was meant for anything coded that interfaces with the Spark API. This would include Javascript based Web apps, iOS Apps, Use of the CURL command, Node JS coding, general API discussion, etc.
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 
I get it.
Spark Official Cloud Base under Cloud Category.
Non-Official Non-Cloud Base under General.
Not a problem.
Understand, Forking now begins.
Filing - it’s always a problem. I think it would be nice were a one sentence explanation displayed next to each category choice when you’re selecting one for a new thread.
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.
Other ideas?
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.
I never said Spark Would Fail; just the oposite. Ebay succeeds for a good business model.
And, NO “People will not have to follow Spark Documentation” like that’s the only way; because its not.
Several people on here on here are working on “Non-Cloud” - “Non-Android” Options; including YOU !
My Suggest was simple, Separate Cloud & Non-Cloud interfaces with a new category. If that doesn’t happen; not a problem. I’ll fork the whole thing.
@BDub - you know your away around here. Pity about the newcomers? I find the categories confusing. Some improvement is a good idea.
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!
Very nice to see that team is evaluating all aspects as they move forward.
Thanks for the update.
Bobby
Always Improving is hopefully a way of life for most Makers. I fully agree. Let’s keep talking about what’s not clear and how to make it more clear without accidentally making it more confusing.
When a new user opens up their Spark Core, they are greeted with this URL:
https://www.spark.io/start
This in turn takes them down the LAUNCH pad of sorts…
Step 1 brings you right to the DOCs… and a whole world of organized knowledge awaits you there.
Step 2 brings you back to the DOCs to help you out with an example, assuming you didn’t read it already from Step 1’s entry point.
Step 3 shows you where to code and program your Core from the Cloud.
The Resources link below step 3 only brings you to the Forums after you have visually scanned past the Documentation and Troubleshooting links.
Let’s say you dismiss all of that, and come on the Forum asking for help… you WILL get it.
I don’t see at what point you will say to yourself, “Wow, this is unorganized and lacking some serious sub-categories… I’m going back to Arduino.cc and I’m going to buy lots of stuff on eBay.com”.
All that said, new users are greeted on the Forum after signing in with:
A good read later and I know how to use the Forum:
I could see amending this Welcome message with a more Pointed overview on everything Spark has to offer… from Forum Etiquette to Documentation, to Forum Categories to deeper and deeper down the rabbit hole.
If you click the Categories button you will get a general description of what each one is for:
These could be filled in a little more, it wouldn’t hurt.
And there’s this discussion happening about adding TAGs to posts… that would help too:
What else?
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.
Is it just me or does “SIMPLE” not mean anything to you.
I don’t want a special anything for me. I AM NOT THE ONLY ONE WHO THINKS it needs expansion.
Again we come to the real issue. If they can flash & use they don’t ned an API Android Solution, RIGHT ?
I believe all points have been made as much as you and I can make them.
We’ve heard from Spark.
The floor is open to everyone else now…
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.