In advance: Sorry for the long post. I hope it makes sense. I was testing things out and coming back and forth to this with new data and ideas. I gave it a final read-through so I think it's ok, but here goes anyway... The Menu-List layout is one of my most used pages. It's simple, easy, and with the new 1.5 features it's very customizable. Idea 1: Would it be possible to have a layout option that aligns the menu at the bottom of the page instead of the top? So if I've only got, say, 3 or 4 items in the menu, they cover the lower half of the screen in portrait orientation. That way, I could place a background image that might have the content of the image towards the top. Fancy titles or text could be placed in the background, then the menu would be lower on the page. To be fair, using a header image will accomplish this task, albeit in a different way. But it might be nice to have that image as a true background image to style behind the menu underneath, giving that full screen background look that only a true background image could accomplish. Wait, I've just discovered a solution: Using the layout type Rounded you are able to input a List Header Height which accomplishes this exactly. So this part of my problem is SOLVED. But my whole goal here really goes back to something I'd posted back soon after v1.5 was unveiled and I'd like to revisit: Idea 2: I have a desire for some textual content at the top of a menu list. Not necessarily in the menu, just preceding the menu. I think this type of layout would be very popular. Something like this: -------------------------------- -------------------------------- TITLE BAR -------------------------------- (an image would be visible here) Here's some important content about our great new such-and-such that you really need to know. It's the most innovative thingamajig to hit the market. Sure, you already have a watchamacallit that does practically the same thing, but this one's smaller, and size isn't everything! -------------------------------- Thingamajig Specifications > -------------------------------- Colors & Sizes > -------------------------------- Email Us a Question > -------------------------------- Buy a Thingamajig Now > -------------------------------- -------------------------------- I guess what I'm having trouble wrapping my head around here is that content should often be the focus, but all my content pages are dead ends, I can't link out of them. Is there a way to hyperlink from within an HTTP page to somewhere else in the app? That would make my day, no, that would make my month. A bunch of menu pages is great to organize information with many levels, index-style, but it's like a website that's only links to more links. I need some combination pages: content + links. The thread I'd first asked about this was: http://www.buzztouch.com/forum/thread.php?tid=824AD1475B7165C&status=&searchInput=1.5%20thanks&sortColumn=FT.dateStampUTC&sortUpDown=DESC¤tPage=1&doViews=1 ...and David you had a good idea, using a header image containing text. I'll consider it as a temporary (but painful) workaround for now. ;) You said that text is complicated and at best pigeon-holes everyone in a same-size-box. I'm good with that for now, really. A same-size-box is preferable to no-box-at-all. And it's much more quickly edited than an image. Perhaps you put in 3 same-size-boxes, like small/medium/large, each with 3 lines, 4 lines, 5 lines, or something. Yeah, I know, I'm taking a one size fits most and trying to make a fashion line out of it, but still. I'll admit, I have little expertise in app design. Ok, none at all. But I'm coming from a long experience in website creation, and I think about the ideal content-heavy app being much like a website, very internavigable. This type of combo content/link menu page is what I feel is missing from the current options. I know I can place content in a background image, but this is tedious. I don't want to have to photoshop text to create content (that I might often have the need to edit later). One way to go about this might be to have independent height sizing of menu items. You could make the first menu item much taller than the rest, and use the Menu Item's Row Title (line 1) and Description (line 2) as the content with a nice paragraph. Then, add the option to turn off the link action (so it doesn't link to another page), and suddenly it's a nice content container, built into the menu. Allowing for independent menu item sizing might be the solution instead of the same-size-box approach. I hope I'm not interpreted as the over-demanding user of the already excellent FREE service. I'm seriously psyched about buzztouch and it's letting me do a lot I never expected. Just want to give some feedback and constructive criticism. You're probably backlogged for months working on new stuff and I'm in here asking for this, that and the other. The fact is, if you didn't touch a thing for the next year, I think I'd still be extremely satisfied. This thing is amazing! Sorry for all the new topics this evening... I've had lots of ideas brewing but want to post them all separately as they are separate issues or ideas.

Don't be sorry, really, don't. Efforts like your putting forth, and the genuinely useful feedback is exactly how projects like this go from cool, to good, to great. Blah, blah, we appreciate it, you appreciate it - good bargain for both. Header Text: I've been engineering this for a few weeks actually. Header text AND footer text, along with the addition of a footer image should be offered and it should be easy and unbreakable. Here's where the design stand now (dev. work at this point, not available to anyone but me me me). 1) Optional header image (three sizes available, no tedious settings to configure the size, pick one, deal with it). 2) Upload crop to the size you chose 3) Header text. If provided goes below header image (vertically below, not underneath image). Two options. Fixed size box with scrolling text. Or, text box height matches mount of text, no scroll. 4) Menu items 1, 2, 3, 4 5) Footer Text (same as 3) 6) Footer Image, same as 1) HTML navigation links: This has been figured out from a code-perspective. What has not been fiigured out is how to show users how to do it without having to teach everyone in the forums, should be easy. So far, the best we can come up with is this: The anchor tag (link) would have a specially formatted URL, the app-owner would have to take a moment to understand this format: -normal anchor markup (forum doesn't like HTML so I'm winging it).... with href = 'nickNameOfScreenToLoad' Seems simple enough? Different size menu-rows: Experimented with this in the early days. Turns out Apple FREAKS OUT and it's totally against their interface guidelines. yeah, I know, lots of examples in the App Store with lots of things 'against the guidelines' but no sense in leading new and aspiring developers down a path of rejection! lol. I think the biggest improvement for the menu list will be some canned, or starting point options. Like instead of selecting 'new menu' when you add a screen, it could be 'new menu style 1' or 'new menu style 2' or 3, 4, 5, 6 where each would have a simple example thats easy to understand. We are not as far behind as it may feel sometimes. There are a few loose ends to button up here n there but mostly v1.5 is doing great. We do need to get Android further along and hope to soon. The hardest part for us is resisting the urge to add add add. There are dozens of features to implement that have already been engineered. Photo uploaders, audio functions 'leave us a message', loads of video functions, location trackers, check-in functions, etc, etc, All leading to a very cool control panel. Hoping to evolve the thing, continue to provide support, and eventually figure out a way to start covering costs ;-)

Scrolling: Genius. HTML nav links: Simple enough. Apple Freak Out: Understood. (Expected? LOL) Menu Styles: Great idea. Takes a lot of time to customize a menu just perfect, then have to do the same thing again and again and again. Might be nice to have it as saveable/loadable theme files like the app themes. Just a thought. Even a few preset styles would be great. Keep doing what you're doing, throw on some price tags, and I think you'll have a hit when the time is right. Let me know if you go IPO. ;) One last thought for the evening: I've been designing apps almost strictly using the iPad and your web interface. I've provisioned the app to my phone, then sit with the iPad to edit, the iPhone to demo, and back and forth. The computer is only needed for initial provisioning. Of course I fall back to it when I need to do some serious typing, but otherwise the iPad rocks. We're talking total mobile development here... that's kinda big in my book. I worked on my first v1.5 app on a cross country flight, and never pulled the laptop out. There might be a couple things I'd do differently on the web control panel to be more iPad friendly, but it works pretty well as is. Just keep this in mind as you roll out the updated control panel. You know, really, you could wrap your control panel in an app, and you'd have the first app that creates apps.

In all seriousness, feel free to edit or delete the above paragraph if you'd like to go with that idea but keep it under wraps for the moment. It would be a decent press-getter, I'd bet.

Last thing... before bed - beat! So... iPad app to make apps, and the idea that this is a good idea and worth keeping a secret. At this point, there are no secrets, it's the internet. Living in public (we all do) does come at a cost. We decided that transparency is better, naive, maybe, comfortable, for sure. Back in the day, we had an app to create apps - it was called, um, you guessed it, buzztouch. It's original incarnation was exactly that. Apple didn't exactly embrace the idea. Bummer really, it worked nicely. So, the next best thing we can do, and the reason the web-interface isn't much of a simulator in v1.5 aligns exactly with what your talking about. The newest buzztouch app (yes, buzztouch app) isn't done but it's not far from done. It'll be a free download, login, visualize, test, play, share your app and content. We are trying to shield folks from having to use the Apple provided simulator. Not because it doesn't work nice, but because it's a major hurdle for new folks to get 'all setup' to just see their app. We think using their actual device, along side their control panel will be much more fun, accessible (no Xcode until your absoultely sure you want to compile / submit), and efficient. Look for this to be announced in the coming weeks. Apple will surely drag-their-feet in approving it but we are confident that it will be approved for a bunch of unimportant reasons. a) Log into your control panel. b) Create an 'empty app', probably starting from a simple template you chose in a wizard type process c) Go to iTunes (or Android) and get the buzztouch app d) Enter your access code e) Enjoy. f) Share, tinker, test with anyone also running the buzztouch app g) Do nothing else if you don't want to. OR, download source, compile, have your own ;-) Night.

Awesome. I sure hope Apple goes for this. I like your approach to development transparency. It takes the guesswork out of it for the user and excites us because we see serious progress as it happens. I can't tell you how many times I've heard the canned line like we'll take your ideas into consideration. We're working hard to create the next version of OurSuperApp but don't have a timeline or can tell you what new features are coming and a year later nothing has changed. Certainly as a product matures, its development pace might slow, but a mature app should be a fully built, hashed and re-hashed, and close to perfect. Your new buzztouch app seems like the perfect approach to keeping users focused on the app creation experience and not having to deal with all that Xcodey confusion at least until the very end. I revisited XCode a few days ago to deploy a couple apps from v1.5. Don't know how I did it, just went in clicking away and assigning code-sign profiles or whatever, and built the app to my iPhone and it worked. It was hell figuring it all out the first time and installing certificates and all that craziness, just glad I got through it. Apple's how-to on their Developer site is not the kind of just plug it in approach I'm used to from Apple products. For experienced XCode developers, I'm sure it's a home away from home, but frankly I don't want to go back in the Apple Developer portal until I really, really have to (when it's time to submit to the store). How long do you expect before the Apple or Google buyout? ;) -- goes to check stock tickers --

Google, Apple, my partner says they may have a few bucks laying around? Funny. Going M.I.A. today, busy schedule - two teenagers keep me running!