I'm new to this but I went into the WYSIWYG for the HTML5 Doc Plugin and noticed that there wasn't an add image icon. It's really pretty pedestrian to not have an image feature - I know there's a background image feature - but what if you want text and a pic in HTML on a page? No Image manager in the control panel is a stunning oversight. Am I right that there isn't one or am I just stupid? (Go easy on me if I am).

You're not stupid. You haven't missed anything. However, this is not a "stunning oversight" nor is it "pedestrian" to not have one. The File Manager is a simple tool that allows you to upload and organize files in a repository on our servers, or yours (in the case of self hosted). It is not a tool designed to help you create, write, or modify HTML. The WYSIWYG editor is also a simple tool. It does nothing more than accept your text or HTML entries (if you're working with the source view) then save the values to a file on our backend (or yours if self hosted) so you can pull simple HTML into your apps. Some folks use it to create sophisticated HTML documents but that's not the intention. In almost all cases, if you need to use graphics in HTML, using a WYSIWYG editor to insert these graphics causes issues the bulk of our audience does not understand. Consider: What happens if you want to the image to be compiled / embedded in the app binary? What is the path to the image in relation to the path the HTML file? etc, etc. There are lots of confusing points that raise lots of additional questions. Like you're discovering, and not liking, the File Manager and the HTML Plugin are not connected in anyway. This doesn't' mean you can't use an image you uploaded to your File Manager (open it to find the URL) it justs means it's not automatic, or frankly, recommended (my opinion). Lastly: It's my opinion that if you're attempting to create anything other than simple HTML output, the HTML plugin is not the best choice. It's usually better to use a Custom URL screen that points to an existing document at a location you control. This could be your website, DropBox, etc. These ideas and opinions are based on the idea that quality is better than speed and efficiency (when creating things). The WYSIWYG editor is great for speed, efficiency, and simplicity but not great for creating high quality HTML output suitable for mobile.

additionally, an image/file manager is a paid for plugin with ckeditor (the WYSIWYG editor used), currently running at around 1400 dollars for a distribution license. Or, if you're using bt self hosted, and you really need the feature, you could do some modding: http://www.mixedwaves.com/2010/02/integrating-fckeditor-filemanager-in-ckeditor/

David - just want to thank you for your generosity in answering my question, even though it contains language that, on reflection, you could easily find to be insulting. I don't mean to be ungrateful for the obvious TON of work you have done to create this community, so if my thoughtless response was in any way prickly or offensive, please accept my humble apology. The point is, I can't help but compare Buzz Touch to Joomla or Wordpress, hence my "stunning oversight/pedestrian" comment. My sincere belief is that you should be able to embed a picture in a HTML doc that is resident on the phone, because speed and beauty should not be mutually opposed opposites. And if they are, my assertion is speed beats beauty anyway because people hate hanging around waiting for pages to load, and I assert that in general, people would expect a HTML 5 function to allow simple pictures to accompany text. I know I'm ignorant but it doesn't seem to be that big a feature. Now I'm not technical, and obviously you have good reasons for your choice of not adding a picture feature in the HTML5 WYSIWYG, but with respect, I have to challenge your thinking on this. Why? I believe a truly successful CMS for Smart Phone Apps MUST have this feature, simply put, it's a reasonable "core expectation" and hence a "Key Success Factor" for a content management system. The fact that this can't be done will be a consistent objection that people will have to Buzztouch. I assert that there should be a happy medium between speed and beauty and adding a simple pic to a HTML5 doc that is phone resident should represent that middle ground. BTW, if it's a cost issue, as suggested by "raveyd", then I humbly suggest that you make an updated plugin and charge for it. Man I'd pay $100 for this plugin because it's absolutely necessary for what I have in mind for Buzztouch applications. I'm sure there are others like me who'wouldn't resent doing the same. So with 14 sales you reach a break even point on the license. Respectfully Yours David M.

PS David - I can't really see a big difference between a background image and a single image on a page. If images are such a problem why allow a background image?

Hi David, no worries, totally understand all the different perspectives we all have. Tons of us looking at these idea in tons of different ways. At first glance I was thinking..."geez, somebody doesn't get it" but I quickly realized (as I was responding) that it's simply a matter of perspective. Mine is almost NEVER the same as anyone elses - go figure! LOL I agree 100% that an image / html / editor solution should be engineered. But, I'm not convinced that the simple online html editors we are all used to (like the free one we're using now) is the best choice. Could be, not sure. I think more than anything an entirely new approach to dragging / dropping resources (like media, images, other assets) onto a "mobile screen" is needed. I'm not sure that HTML is the best way to do this. There's huge difference between HTML in mobile and native in mobile. We like native but also understand the benefits of html. And, for sure new folks need to use html in cases where they don't have the skill or patience to try to pull it off natively. We feel compelled to allow folks to use html in their apps but also know that it's rarely the best approach. Giant balancing act between what's best and what's easiest. I do look forward to the day where we can help "assemble" their content (different than authoring content) in more meaningful, efficient, and professional ways. The background image and single image on a page have entirely different benefits. It's not easy to understand this until you've seen thousands of screens with tons of different designs. For sure it's not something that needs to be understood but allowing both does allow for some flexibility. Examples... --Background images (cached on the device) "underneath" some clear / transparent HTML is a great way to load fast and pretty content without having to re-load an image with all the html each time. Think abstract backgrounds, like the background on your computers desktop, mine is Blue Swirls. --Some devs create "320's" (slang for full screen image in iOS) for each screen and set these as the background. In some cases they even add all sorts of controls and widgets to these backgrounds for the sole purpose of prototyping. It's amazing how "real" an app can look by using nothing more than specially designed images on each screen. One image, one nav bar, click around and it feels like an app and helps the design process. Another trick to speedy design is to assemble all the screens (using custom background images for each screen) using the HTML plugin. Say like 15 screens, each with a specially designed background image. Next, app designers can add simple notes and comments in the html that gets displayed on top of the image. Again, this approach is just for prototyping and client discussions. Makes it easy to see what each screen should look like and the comments are notes about the details. We could talk in great length about this stuff and I would love to get the chance to do just that someday....too bad you're 17 hours away! Cheers.