Important question regarding next major Rev version

[valetia @mac.com]

Thanks all for your comments. The people at RR have gotten in touch with us and we have provided them with a concise list of specifics that need to be worked on...

Apple has very nicely summed up the benefits of having apps look and feel like other apps, at the following URL:

http://developer.apple.com/documentation/LegacyTechnologies/Conceptual/AquaHIGuidelines/AHGIntro/chapter_1_section_2.html

In particular, have a look at these points (extracted from that page):

- users will learn your application faster if the interface looks and behaves like applications they’re already familiar with

- users will accomplish their tasks quickly, because well-designed applications don’t get in the user’s way

- your application will have the same modern, elegant appearance as other Mac OS X applications

- ** media reviews of your product will be more positive; reviewers easily target software that doesn’t look or behave the way “true” Macintosh applications do



Alex Rice <alex at mindlube.com> wrote:

> Those who can respond in detail to what's in the next release are under 
> non-disclosure agreement.
> 
> But I sympathize and also wish for more "roadmap" types of 
> announcements from Runrev.

Yes - these are sorely needed. I can see where you'd need an NDA if you're going to be rolling out features that most competitors don't yet have, but for basic necessities like native look and feel support for all controls on all platforms, there really isn't a need to put them under an NDA...



Chipp Walters <chipp at chipp.com> wrote:

> Ever since I started programming, I've commissioned externals 
> to do the things the programming environment couldn't do. I think that 
> is valid advice.

While that might be useful for things like browser plug-ins, I don't think it's efficient to commission externals for basic look and feel components...simple things like menu bars on windows don't look native at all, combo boxes look fake, etc. These should be built right into Rev, because Rev provides these objects for use.

> In many cases, I want the power and capability to 
> edit the function of the control...something you can't do in VB as it's 
> an ActiveX component. So, I roll my own, just like the VB guys do. In 
> fact there's a cottage industry built up around roll-your-own ActiveX 
> controls in VB. You can get different lists, trees, buttons, tabs, 
> toolbars -- all for a price. You can do the same in RunRev. I wrote a 
> XMLtree control one time, and use it in about 8 different places.

Yes but these are more complicated controls - I'm talking about simple controls like menu bars and dialog boxes (which look like they're just "stacks in disguise", which they probably are)...

Look at the size of that arrow on a rev combo box on OS X, and compare it to the native one. And it looks plain ugly on Windows XP compared to the real one...

I understand 100% what you're saying about using externals for things that don't come built in but you know, it's just not efficient to have to implement them just to show native controls...


> Perhaps if you post a copy of your
> stacks online, some of us may be able to help you make them look more
> professional?

That just proves my point. You need to "hack" stuff to make your apps look normal with rev! That's not what we should be spending time on, especially with a Rapid Application Development tool...we should be spending time on the actual code itself...


> Geez, now it sounds like you are just whining. <snip>
> Why would you posit such a ludicrous statement? I know that I care about 
> interface issues *very* much. Frankly, now you're starting to sound like 
> a Marketing person from a competing company.

Well, here's a comment that shows how I'm obviously not a marketing person from [insert name here] - their programming language sucks. Transcript simply rocks!!!

Unfortunately, that competing company, [insert name here], has native widgets built in for all 3 platforms. Compiled apps look *just like* apps built using vb on Windows or project builder on the Mac.

Apparently, and this doesn't seem obvious to some, one of the main reasons so many people still choose [insert name here], and are calling RR a toy or multimedia tool, is the clunkiness of the look and feel of RR apps.

You can't change the programming language easily without affecting existing developers, but you can certainly change the way it handles look and feel objects while keeping the same programming language. That's where RR has the advantage, if they want to utilize that - and that's what needs to be pointed out.

Val