A feature I miss from v1.4 is the ability to upload images via the buzztouch interface, for example when setting up a header image in a menu list. The uploader's cropping feature made it extremely easy, as I could just pull an image from my library without worrying if it was the exact size for this purpose. Is this feature officially deprecated, or is it something that might see a return in an update of v1.5? Right now it seems my options are to add an image directly to the downloaded source code, or load from a URL. Both of these will ultimately have the same result, but I'll have to say one of the things that attracted me to buzztouch (and still does) is total ease of use. Uploading an image was easy. The new options add extra steps. I like easy. I will say that ultimately I like the idea of having images self-contained in the source code... ultimately. It's less data-fetching for the app. But this means a lot of work to properly crop and size and manage a bunch of extra files. And not having finalized on my app icon, I know I will have to download source code again and then have to move files into the new source code. Probably not that hard. But again managing all these other files adds another layer of user action and lowers the convenience of the system. Lastly, I've noticed the areas in the control panel referring to images (such as the header image in a menu list) don't specify the ideal pixel size. So, my vote: bring back uploading?

Smiling. Yeah, uploading is a major discussion topic. For one group (your group), uploading made sense mostly because of the simplicty. I totally agree that this is easy and should be included in this release and future releases, it feels 'core' to what we do. The other-group is the group that is hard-core about NOT being forced to park, store, upload, anything to the buzztouch servers. There's a large group of users that use the interface, then disconnect from the control panel and park the configuration file on their own servers. This is the biggest reason we went with the current design, to allow folks to 'point' to images wihtout sending them our way. However, you hit on something earlier that makes sense. Maybe allow uploading, but instead of telling the app the URL, go ahead and include the previoulsy uploaded image in the downloaded project so it doesn't need to fetch and cache it? Hmm.. The only drawback to this approach would be updates. Because the image was included in the project, it would not be updateable from the control panel. In other words, it would be compiled in the source - permanently. Hmmm... As far as sizes go, we do have lots of work to do on examples, docs, tutorials, etc. v1.4 forced folks into a header-image-size on the one menu that allowed an image. v1.5 is super flexible and as such all different kinds of image sizes are being used. Large ones, small ones, tall, short, etc. The layout's are no longer fixed. But, this doesn' t mean we shouldn't lend some direction, pointers, etc. I hope you understand how much we appreciate your insights, taking the time to write such detailed comments is reall really helpful. Thanks tons for this. We'll consider the things you've described and see what we can come up with. I'm thinking it'll all work out one way or the other ;-)

David, you're working late! I like your style. (midnight here on the east coast) I'll have to say that without an option of uploading images, you're perhaps shutting out a lot of possible users. The tinkerer type that wants to give it a shot and see if they can create an app and then turns into a serious user. I'm one of those, I guess. When I started my first app, uploaded my first picture as a menu header, and saw the simulator shot on the website (as it does in v1.4), I was hooked. For the psychological success moment it yields alone, bring it back. ;) I really believe it's a big part of your success. If I would have had to go through all the horribleness that is the SDK just to see my first partial app in action, I wouldn't have made it, I don't think. From my perspective of creating websites, it's that ease-of-use I can do this feeling someone gets when they use a tool like iWeb or Rapidweaver versus something like Dreamweaver. It's iPhoto vs. Photoshop. At the same time, the finer points and advantages of incorporating images in my source code or hosted on my own URL is not lost on me. Ultimately I will be using more and more of this approach. But the quick and easy upload/crop tool you have on v1.4 is stellar, and key for new users. I also can imagine you might want to get away from the data load that hosting the images on your servers might eventually create. All it takes is a few more users and a few wildly successful apps and you are going to need a Google style server farm. And I'm guessing you desired path to monetization is not fixated on being an image hosting service or bandwidth purveyor. Focus on future premium feature activation to transform free users into paying customers, rather than data rationing. I really like the fact that you guys are so open to client feedback, in a real way. It will make it real easy to give you money once you do make that transition. You're really out to make a killer product, and that's what we're all looking for. The fact is, it's incredible already. The frequent updates and additions just make it that much better. I'm glad we're talking about changes and ideas that might happen in days, weeks or even a couple months, and that we're not just waiting another year for iBuzztouch '12 (if you know what I mean).