Hi gang... We are writing to get some ideas and some feedback about something that's been bothering us for quite sometime. Last year we released buzztouch, v1.1, then v1.2, then v1.3, then v1.4 to see if anyone wanted to 'do this.' As it turns out, a super-huge audience has embraced our concept and more than 40,000 apps have been created using our tools - awesome. We listened, learned, improved and v1.5 was released for iOS earlier this year and offered all sorts of options and flexibility and improvements over all the previous versions. v1.5 for Android will be released in a few weeks. We are excited about v1.5 for Android and look forward to seeing all sorts of new creativity. However...a bad trend is emerging... Thousands of folks are creating apps that don't perform well, especially when they rely on an internet connection. These apps are generally rejected by Apple but not always. It's amazing how many apps are in the App Store, created on this site, that perform poorly. Don't get me wrong, there are also boat-loads of apps that perform awesome - like we intend, but for sure lots of them need major improvement. And, it's not Apple's rejections that bother us, we would expect nothing less of them, nobody wants low-quality apps. We are bothered by the idea that Apple's having to reject more and more buzztouch apps over time because so many of them are being submitted without proper testing or quality control. You can't imagine how many apps are just 'sent it' without any testing at all. Really, come on, at least put it on a device before you send it in! Funny. In v1.4 there were few options and most of the apps worked exactly as expected. It was much easier to control the quality with so few options. With all of v1.5's awesomeness comes some trade-offs, namely that it's so flexible that it allows folks to BREAK IT and it makes it easy for a novice to create a really bad end-user experience. Lots of this is simply becuase the app owner doesn't understand how it works, what they've created, and how to improve it. We all want good apps, this isn't a rookie-bashing post, it's just our way to say we really want to see the highest possible quality come from our site and we are sensitive to all the different skill levels and interests. We are sincere when we say we want to help - bogus apps are good for nobody. So, what do you think we should do to address this increasing issue? Add some comments, idea, feedback. Should we continue to make super-flexible features with the understanding that some of the results will be low-quality? Should we focus on making easier to understand, but far less flexible features that 'just work'? Should we, the audience (you're in the group) figure out way to increase the quality of the apps while also allowing tons of flexibility? Not sure how to best do this. Any and all feedback is appreciated...

Problems: I think most of the bad-user experience happens because the app user doesn't understand how it works. Maybe we could write a few sentences(common for all of us to use) in the app explanation, like a how-to, lots of reviews I've received has 'empty screen, give my money back' or 'doesn't work, blank screen only'. Most of them doesn't know that they have to refresh on the first use(if we didn't copy BT_config just before submitting). I have also heard that there are some users(not app owners) that loads the app and immediately returns to home screen(iOS). And on my SVGN 2012 app, youtube videos play on iphone but not on ipad. This is a bad thing because videos are an important part of my app. My suggestion: I think we must try to help finding bugs and telling them to you(buzztouch) so you could make v1.5 more stable and bug-free in the first place. Maybe you can set a date for this like, end of september or october. After the big portion of the problems are gone, you must release v1.6 or even v2.0! :) After the first step, I like the idea of 'the audience figure out way to increase the quality of the apps while also allowing tons of flexibility' solution that you offered. Finally: You're right that instead of, out of 40,000 apps, 5,000 working like a charm, 25,000 not perfect but works, and 10,000 buggy apps; 20,000 working like a charm, 15,000 quite good and 5,000 less buggy apps will make you and us all happier. And will also have a big role in buzztouch's good advertising. Of course waiting the problems solved by you is not the way, we(the app owners) must try harder to create our apps more understandable, rich by the means of graphic, design and content, and share every problem with buzztouch. Again a big thank you for providing us with a product like buzztouch David & all the others...

Hi David. Well said, and I completely understand the concerns. One of the things I've greatly appreciated about BuzzTouch is that it's powerful enough to allow me to really push the limits. I've tried a couple of the other services out there and nothing compares in terms of flexibility and ability to truly customize an app. One of the challenges of your business model is that there are people of vastly different technical and graphic skill levels using BuzzTouch. You've opened the door to allow the average Joe to create an app -- and that's a really great thing. But couple the ease of use with the natural excitement and impatience in trying to get something finished and you'll get some poorly crafted and tested apps in the mix with a lot of truly outstanding apps. You put a powerful tool into the hands of many. But as Uncle Benn said, with great power comes great responsibility. Not sure all of the BuzzTouch community realizes that. *** As developers, we have to be responsible to properly build and test our apps. *** That's the bottom line, and I don't know how you teach that. The last thing you want is for apps from BuzzTouch to be flagged by Apple for special review because of historical problems. I know the message boards at AppMakr had a number of posts about AppMakr apps being rejected or more scrutinized than others because of poor quality. Personally, I'd like you to continue to add even greater flexibility and customization options. I'm really excited about 1.5 for Android, and then for html5 and windows. That helps me tremendously in marketing to clients -- knowing that I can offer a multi-platform solution. Perhaps you'll find your business model requires moving to a paid or subscription model for using BuzzTouch. That will certainly thin out the crowd of users. Although, in my case, I most likely never would have started using BuzzTouch if there were fees involved. It's certainly a double-edged sword. Now that I've learned how to build apps, and I've had some success with app sales, I'm happy to chip in and pay a fee. Funny how that works. In fact, I'm willing to help wherever I can. I've tried to lend a hand in the forum to help others, because I've asked my fair share of questions and been helped tremendously. Another thought is a stair step approach. Perhaps you force users to develop several apps in 1.4 before they are allowed to upgrade to 1.5? You could also separate the forum into 1.4 and 1.5 sections. Users wouldn't have any knowledge of, or access to, 1.5 information until they've proven themselves with 1.4. Don't know. Just a thought. Thanks for asking for feedback and for developing such a great product. Looking forward to all that's coming down the road.

I think having to get into the code of a v1.4 ap to make adjustments & changes etc is a good learning ground for understanding how things work I would think that part of the criteria for being an 'Early Adopter' would be to have successfully created X number of v1.4 apps first before moving on to something more complex such as v1.5 (which actually requires LESS need to modify any code in XCode or Eclipse) but at least the user would have a better understanding if how different elements fit together As an additional note, a LOT of questions that get asked on the Forum AND that I get asked personally via email, Skype, GTalk etc are questions that are easily answered if the guides and videos has actually been followed - maybe to make studying of those a mandatory thing to do before proceeding with app building

Interesting post David. Will offer up my 2 or 10 cents later in day. Think the excitement of being in the biggest company in the worlds store makes folks a little giddy, it does me anyway! I'm not saying I haven't made mistakes and did have two apps refused on first attempts, they where pish to be fair. I didn't fully understand the intricacies of the review process or what is expected of a native app and did have the apple stars in my eyes. Apple will - without explicitly stating it - ban devs that keep submitting pish. I cannot imagine their fury when they come across something that has not even been fired up on an iPhone, nevermind iPad or proper testing. Hey, shove this in your store, not sure if it works but I want folk to buy it under your umbrella. Hmm. I have also noticed an increasing number of posts that have begged the answer did you test this before submiting? Not only infuriating for apple, devs et al but infuriating for you BT chaps, it dilutes your brand, whether they mean to or not. Anyway, busy AM ahead, will read back through the post later in day and add what may be closer to my 8 cents. Cheers again David, can't say thanks enough for all your hard work and personal help from the off.

David, I feel like I can really sense your frustration undertoned in your message. I've had huge projects (prior to app making) in the past that I put a lot of work and love into, and had to watch some end users mis-use them. Its a painful process. My initial thought after reading your request was to simply charge for BT, therefore making the developers commit more than just time to get their app finished. This would help thin the crowd as said above. But I also realize that there is the initial fees to apple which serve as the same purpose. So I'm not sure if that's the best solution afterall. For me, I studied how the whole BT thing works. Read the forums. Asked the questions. And finally set my plan into action. I decided to create my app with BT's awesome tools, but then sever it completely from any future need of BT (all data stored within app, and no config urls, etc). I did this to allow any i-device user to download the app, and never need internet again. Its more work for me in the long run (updates, etc). But I was focused on the end user's experience. I think this is why it had zero problems making it through the apple submission process. I mention all this to try to persuade you against any must make 1.4 apps before upgrading to 1.5 type plan. If I was required to make some 1.4 apps first, I would have spit out a bunch of crap apps real quick to get my requirements in - which is exactly what you're trying to avoid right now. So to sum it all up (if anyone is still reading my ramblings) - I'm not sure if I have a suggested solution. I would say continue to add features and grow this community, which I can tell is deep in your heart. And hope that your users do more good than harm in the long run.

hi i am very new to this App thing and i found your site good and very easy to use, very pleased, but i know this bit is not realy anything to do with you as such but some more info on setting up Eclipse and the adndroid SDK and the ADT bit would be very helpfull, i have verly set it up now but it has been a long slog still not magaged to compile my first app yet (still working no it)

@Kidguy - No offense but please you are way out of topic. Use the forum correctly by searching solutions for your problem. Anyway. My thoughts on the topic is splited. In some ways I think some kind of performance demands could be useful for sorting the bad apps from being uploaded to Apple. But as many have stated - if I was forced to develop a couple of less good apps in order for accessing the possibility to develop better apps I probably would create just bad apps in the first run. The charging method might just work, but this can also mean that BT will loose customers in the long run. I would definitely pay. One way can be to completely remove any connections to BT? I know that this sound weird, but hear me out; In the license.txt there is clearly stated and reasonable text connection the app to BT. An I guess there is more of those connections to BT in apps. If a increasing number of bad performing apps is pointing towards BT this is obvious not a good thing. But what about the good apps? Well since BT have a database of all the apps the filtering for promoting BT would be focused on the good performing apps and highlight them only. Another method can be charging creation of a new app. As it is now I can create as many as I want. If this number was set to lets say 5 free apps, maybe the number of sended apps would increase? But the main problem is that we (all) as developers must be much more critical and really make sure that our apps perform well. BR/Stefan

I am still developing my app and have done for the last few months - it has been incumbent upon me to get it as right as I can - I watched the tutorials several times( I wished there were more and in depth ones at the time, but I learned all the same). I read the forums, I trialled and erred my way thru the process of understanding BT to figure out how it worked. I viewed as many apps (including ones i knew were BT jobs) to calculate my way to where I am currently -I conclude that usage and practice - make perfect = I am still chugging along mulling and weighing things as I go - this type of diligence is all that is required - i have changed the structure of my app and my business model several times since i began - all to get what I believe is just right, for my app - I am probably a month or two away from completion and am reasonably comfortable with what I have done thus far. I don't mind patiently building my app a step at a time. NOW - As much as I am grateful and appreciative of BT - I have to stress that there comes a time when even a car maker must allow a driver of that same car the full responsibility of what they do with the car - these are early days - It has been my responsibility to build this app and no one else - there is a level of self discipline required here - If Appmkr is experiencing similar if not worse outcomes then this too is indicative that you can make a great car but lousy drivers crash them and that friends is life !!!! i am sure that more comprehensive screencast tutorials could be helpful in at least raising the statistics for better apps. But no amount of effort will eradicate what is really bad craftsmanship and inevitable to appear. I can see David that you take this all to heart and this is admirable of you. It displays your deep sincerity that all the members recognize and appreciate. But I sense you need to appreciate that this will and does happen because of the choices people make. What you can take pride in, and focus upon is the fact that so many people want to pursue and develop this field and you have helped them to achieve what has been a hamstrung field to enter, even for lousy app makers - These are early days, a teething process. While BT should be concerned about these outcomes - i don't believe BT needs to take all the responsibility - this is quite unfair - I am sure that our community can evolve, help one another and advocate continuously, the importance of quality and testing - but it should not detract BT from its course. Some here have suggested charging - I don't think that is really achieving much in the long run - I think the tutorials could be extended to help lift peoples understanding - and an emphasis on quality needs to be cultivated within the community and failing that: a clear but fair stipulation to members within the terms and conditions of BT usage and consequences perhaps. Again many thanks David and the BT team.

hmmm double post .... there you go im still bloody learning .... (sigh)

My view on this is coming from someone who in the early days was conversant in machine code and early languages for writing games on old 8 bit computers (you got to love the spectrum and C64) but who has transgressed into a user of software not a developer. BT with its fabulous structure has lead me to becoming a developer again, it takes away the difficulties of a mass of coding and guides you in the most important part of that app which is function. You then need to marry that up with xcode and very specific and at times convoluted processes such as changing code signing from developer to distributor. None of these are difficult once you know but are easy to miss at first. Speaking with the experience of having two rejections for my first app due to what I think as errors on my part of not understanding the root structure of the files (I use think because at present I, David and a bunch of BT users are helping this unresolved problem), a great deal of the onus is on me and other users to scrutinize every part. I assumed because app was working fine on my device and in the simulator it was fine but this is not the case. Before I submit app to iconnect for the third time I will get another user to test it via a service like test flight etc, (any taker for my first app would be gratefully received). I think its an obligation on us that due to how BT has treated us we must not sully the name of apps originating from this great service. One idea is that BT offers a service once the app is completed to be verified for errors and that it does not put adverse strain on the phones/pad processors. This I think should be charged and one be one method of verifying a basic quality of app. Maybe when a user has a rejection (like me), prior to putting it for resubmitting they may need to have it verified first. And user who consistently upload good error free app would be able to skip verification Another small help would be a small checklist PDF that user could download to self asses that they are ready to upload to the store, if this had common issues i.e Codesigning ect that cause problems that would help all less knowledgeable. I must impress on buzztouch that what they have done with this service is open up a niche world of app development from programmers to everyone regardless of Java/ C knowledge. Ideas are always the spear tip to great things and all we as a community need to do is support BT in ensuring that the spear shaft is of sound quality and represents Buzztouch and its community accurately

I suggest an online tutorial and then test with a minimum pass rate. Nothing too hard but enough of a process to filter out folks who arent serious about validating thier own apps before submission. I think this would deter folks not willing to make the extra effort and thin the heard some. I know I would have push through it. You could put some BT code of conduct stuff and emphasis on checking your app first etc... My 2 cents.

All those blank screen complaints which I think many BT developers are getting because end-users don't know that they have to tap refresh would more or less be fixed simply by removing the option of doing real-time changes to screens and menus. I am sure MANY will disagree with me when I say this (BT team included) so please don't shoot me, but I think that this option may be doing more harm than good in regards of end-user experience. A lot of people are probably submitting their apps way too early in the process because they know they have the opportunity to tweak their apps in real-time through the control panel. All of my apps are purely offline-working apps. By making all my apps this way I am sure that what I see on my iPhone, is what the end-users gets. It also forces me to make sure everything is working well and quality-check before submitting, because if I want to change anything I will have to go through the somewhat tiring process of re-compiling and submitting an update to apple. However, I find it VERY useful in the development process - having the opportunity to make changes and refresh to see the result instantly while testing. The quality of the apps that are being made obviously also depends on the BT-users own will to gather some additional knowledge and understanding, even if BT has made their service as intuitive as possible. BT-users should read both the 1.5 documentation and study the forum-topics. Even with buzztouch's ingenious solution, it does require some effort from the developer. It will be one of BT's challenges to make their users realize this. I hope more users will make an effort themselves to create quality apps that reflect the greatness of Buzztouch

Exactly, Captainash. Perhaps BT could require a finalization step before submitting to apple that removes the live update feature. That's how I'm doing my next app. I'm taking advantage of the live update process during development - so I can compile and install once on my devices. And once I have the app exactly how I want it, I'm going to remove the config urls, and replace all the image and document links with the actual data included in the build. (and re-test on each device again, of course).

I agree with captainash and stobe. All of my apps are purely offline as well EXCEPT for the version on my phone. I admit I like having the ability to continuously update my phone as I go along. However, it seems like so many people have problems submitting apps with an old config.txt file, or have issues trying to update their apps while live that it may be best to avoid that feature altogether to improve the quality of apps seen by buzztouch. Maybe you could make it an advanced feature? Either paid or maybe one earned after submitting so many apps? Another possibility is to have a paid service where users could email you their binary for review. Then you could (at least I think you could) check out the final version and offer advice. Or you could even just have them do that for their first app before they're given advanced status and allowed to create more.

Hey David, I have been an early adopter for a few months now and have spent many evenings just reading through the fourms, learning, learning and more learning. There are many good insights on this posting... It is true that bad apps reflect negatively on BT and that just isn't cool. I read on a post about a possible paid membership for a more advanced version. I for one would be most interested in such. For those that are currently early adopters perhaps a discounted fee. One of the common issues I have seen throughout the discussions is like mentioned above, some do not seem to understand that there is much more to creating a quality app then menus and copy... And test, test and when one feels they are ready test some more... A few extra days or a week or two longer to test is not to much to ask... For BT to become a policing site/company that would truely take you from developing newer add ons and versions and none of us want to see that happen(right)? I'm afraid there is no cut and dry solution and not everyone is going to be happy. As a developer and member of the BT community I will do my best to be an example as many already are... As a person that uses and plans on using your platform for a long time to come, I am more than happy to help any way I can... One final thought, perhaps those of us that understand the importance of a well planed, designed and tested apps should start posting thoughts and tips that encourage quality not quanity... Thanks David and everyone at BT for the great work your doing and for raising the flag on this issue....

I thoroughly disagree about removing the live update feature. It's a great tool if you use it properly. That means downloading the final BT_config.txt before submitting to Apple. If there is a bad user experience, it's because a developer has jumped the gun and not submitted a properly finished and tested app. There have been feature requests I've had from customers, and I've been able to make the changes and have an update ready quickly (sometimes practically instantly). The users appreciate that tremendously, and it sets apps made through BT apart from others out there. @Anarchy - Totally agree with you. Test, test, test. So important. Thanks again to David and the team for a great platform.

Wonderful, thougtful, and genuine insights - great stuff here. I'll save the sappy thank you's, you know we appreciate it. The good news: Exactly zero of these ideas are 'new' to us, we've discussed all of them and others for several months now. The better news, all of us seem to agree that quality is important and a little extra effort on the part of the developer is important if an app is to have any useful purpose, meaning, or possible success. I'm a huge fan of training and more than anything I think we need to focus on that aspect of how the system works. Put another way, organize the help-topics, videos, and forum so it's easier to experience the goodness and get rid of the bad-ness. Regardless of what adjustments or changes come from all the great comments, we'll for sure begin spending more resources on buzztouch U after v1.5 for Android is sorted out (we expect a few weeks of necessary adjustments after releasing it). I'll move this post to the top of the list in a day or two so it stays near the top of our ghetto-forum -;)

Maybe there's an option for some of the more experienced users to act as 'pre-testers' (assuming they had the time and inclination) for newbies or the anyone. Maybe for a small fee a bit of testing and critical review from an experienced pair of eyes might help - I'm sure most people would rather spend $5 or something than spend two months going backwards and forwards arguing the toss with Apple? The community here is becoming more and more active so it's a resource that could be leveraged.

First of all us rookies should get bashed, it's a right of passage! :-) I have a somewhat different perspective...maybe. I like 1.4 because it's easier to use. I'm probably on the low end of ability with programming so I know I won't get in too much trouble with 1.4. The thought of having to learn 1.5 is not a wonderful thought for me because I know I'm adding complexity, and where there's complexity there's fragility in more ways than one. I know it's tough to communicate that idea to an end user of BT because most of us just want stuff to work. The problem as I see it is that the end user of BT or any other app/software/whatever doesn't know why something went wrong, most end users do not think that they are the problem and are in over their heads (this is not a rational thought considering they have never used Eclipse or Xcode and opening it the first time SHOULD be an indication that these tools need to be learned). This is HUGE and not easily fixed. I think you should do as much as you can to make the process of creating an app easier to understand. From my point of view humans usually don't understand something because we don't have a big picture of how something works. The bigger the picture one has only means that the problems one can fix are directly correlated to how much they understand. Sure, I can figure out how to download the source code but do I know why Eclipse doesn't SEEM to be working right when I bring the code in? NO, but I should know that I need to know why. I want to avoid Eclipse as much as possible but the fact is I NEED to understand more of Eclipse and what it can do if I want to get my app into Market. Every step of the way of learning how to create and get an app to market is deepening my understanding of app creation, Xcode, Eclipse, etc... How can BT facilitate someone learning or understanding the bigger pictures? Is it even BT's responsibility? I ran a tech support dept. for 3 years. We took as much responsibility as we could and I still had to get on the phone and explain, in a nice way of course, to a pissed off user that they didn't know what they were talking about and the problem was with their lack of knowledge about how their computer works. Sound familiar? There's only so much BT can do. Having said that BT does have a lot of users who are learning the process and do (want to) take responsibility. Is there a way to create some kind system that helps us take more responsibility by understanding what we're actually doing? What is being affected by changing this and that. As an example I've found some fixes for some issues but the BT file names were different so I didn't know what I could change and what I couldn't in the lines of code. (Again lack of knowledge cripples my ability to act) Explain upfront that BT is easy to use (create apps) but complexity is hidden to make things easy to use and if you mess with it too much you may experience significant problems for yourself and the end users of your app. Create a resources page that has direct links for fixes to common problems. Look to your users to come up with some good links and info. Encourage users to post after they've fixed a problem, added to BT's capabilities in a new way or solved an issue that could help others. Then set those aside and somehow use those fixes etc to support the users. Have a tiered system (I have no idea how you could even do this so please forgive me) Simple App: Have an up to date simple system like 1.4 that works with the latest OS's. Some kind of medium complexity and then a system that advanced users can use. Of course it needs to be scalable. As the user learns, they have a place to move to. Or maybe sell it that way. How many users are using 1.4? How many are using 1.5? Could you find out what is breaking the most? Can you narrow down where the problems seem to be in the broke apps and directly support the fixing of those issues by offering some resources to us that are outside of the forums? Can you grok from the forum what the top 20 issues users post about? Mix that with BT's perspective. Then offer some videos or explain why the issues occur (if you can). Encourage those who understand more to offer paid services to help those who don't know how to fix their problems. Expand the forum to have topics that are part of the app creation process but not necessarily just about BT. Example: Getting ready to submit to Apple, Getting ready to submit to Market, Eclipse, Xcode, safely altering your BT code, etc… Have them be user driven. There's enough smart people here to help with stuff. These are just a few ideas. I can see they are all fraught with problems too but you asked… :-) I think you should 'focus on making easier to understand, but less flexible features that just work.' Notice I took 'far' out of your sentence. In a nutshell I guess I'm saying that BT needs to provide more support but in the true sense of the word not in the hire more support guys to put out fires sense. BT also should be very clear that it's the end user of BT that is responsible for the success of an app. But I'm biased toward this answer so take it for what it's worth. David, you are doing such a great job at supporting us, I don't know how you do it. You should take pride in the fact that there aren't a lot of snarky or nasty comments on the forum. That is a testament to the good vibe you project while answering so many our lame questions. ;-)

what about a couple of options.... basic user and advanced user. then if someone uses the advanced and their app is rejected, it's down to them - and if someone uses the basic, they're more likely to get the app passed, but will have a little less choice feature-wise. the ability to change an app from basic to advanced and vice versa would be nice too.

I like the idea of having a simple and an advanced mode. Just put a disclaimer saying that by using advanced mode they are accountable for any bugs and issues in they're app.

I like the idea of having a simple and an advanced mode. Just put a disclaimer saying that by using advanced mode they are accountable for any bugs and issues in they're app.

Some great ideas here! As a teacher, I know how difficult it is to provide tools for a wide range of ability levels & sit back & watch weird things happen - but then, that's how amazing things happen, too! I agree with Marko's ideas - checklist + BT checking b4 submission. I also like the idea of moderate + more advanced modes - let the user decide what level of input they want. Like others have said, screencasts are definitely the go!! A really effective tool! I like the way v1.5 has tips & explanations & suggested starting points for some of the options - very helpful! I would even go so far as to suggest perhaps a default setting for most options, which developers can leave as is, or customise using the tips & videos. Further, I would suggest some more 'leading by the nose', where you go from step 1 (make pages) to step 2 (make menus) etc... ie set up an optimised 'pathway' through project building process, while still maintaining the option for developers to go back + forth + in + out at will. Don't be discouraged & go down the path of making it difficult for people to access more powerful tools... It's just like public service industries have to do - educate clients with a vast range of skills, abilities and understandings. Maybe learning lessons from how they educate might help...?? Simple, short statements, anticipate client errors / misjudgement....??? I'm sure you've had all these ideas already, but the tough part is deciding the best direction for investment. Good luck with it!!

Late post as this thread was started before my time, Oct '11. I think the biggest problem is that users are so thrilled to have and app they just want to get it on their device and iOS apps mostly have to go through iTunes. I bet that there not the same problem with Android since the options are greater, but my two complaints about Android Market are, ability to find and app & quality of apps. If you were to explore usersability to jailbreak and install their iOS apps accordingly, your Apple iTunes Store worries will mostly disappear. Thanks for an Absolutely Fantastic Product. Fred