In less than 24 hours it’s gone from the 4,000-ish rank to #11. Feel free to make it one of your priorities and let your voice be heard. If the Feedback system is truly the way to get things to change then this is our opportunity to test it.
I think we’re all fed up with half-baked and incomplete new features. Lack of documentation and examples aren’t helping us either. It’s to the point where each new release brings it own new set of problems. Each release causes anxiety rather than anticipation.
It makes using REAL Studio a pain. During the 2010 Release 3 cycle, the huge memory leak issue in Windows was causing me to revert back to Release 2 which also had its share of issues in Windows. I seriously debated if I had to go back to Release 1 or even earlier. Thankfully, RS decided to do a dot release for R 3.1 and subsequently R 3.2 but testing those two releases kept me from testing R4.
To be honest, I’m not opposed to the 90 day release cycle per se. I have a huge objection to the way it’s currently handled.
There doesn’t seem to be much planning going in to each release. It seems that the RS engineers are told to develop something new. They start development in *that* cycle and it gets added and released in *that* cycle. This leads to a lack of examples, lack of documentation, and features that are half thought out with too many outright bugs.
Here’s an idea: Anything added to the project *must* have an example project that exercises major functionality. Ideally it would tweak all properties to ensure proper functionality. This does several things:
1) Ensures that the feature works as it was intended by the RS engineer
2) Gives the RS internal QA staff and management something to verify before it’s released
3) Gives beta testers a reasonable example to start from. It becomes the de-facto baseline project for the RS engineers
4) The project becomes part of the official release and gives end users an example to use and learn from even if documentation is missing and/or incomplete
Let’s face an inconvenient truth here, shall we? The 90 day cycle is too fast for PROFESSIONAL users. There’s a reason why no other development tool uses that fast of a cycle.
RS needs to properly plan features out. They are in the R5 release cycle now so any new features not already added for beta testing can NOT be added until the 2011 R1 release. This also means that any major bugs found in a R5 feature be pulled from this release.
I don’t know if this can be done given current engineering leadership and personnel. If certainly feels that the current release and feature schedule is *marketing* and *sales* driven and that quality is not “job 1″.
Personally, I’d be happier giving my money to RS knowing that each release is as solid as they can possibly make it. I’m okay if that means that a release takes a mere 60 days or takes 180 days. A solid release means more to me than incomplete new features. Circling a date on the calendar as a drop-dead date is fine every now and then but it shouldn’t be an every release occurrence.
Some have asked why me, of all people, is forcing this discussion. The answer is simple. I use the product all day long, six days a week. I really, really like it – it’s the only product I’ve found that’s quite like it. It puts a roof over my head. It’s a good product now but it has such great and awesome potential. However, each release brings new problems and new pain. I’m getting old enough to know that I need to stop banging my head up against a wall.
I either effect change or move on. This is my attempt at changing RS for the better. Maybe they will and maybe they won’t. At least I can say I tried and I’ll have no regrets either way.
My Saturday was supposed to be dedicated to a training video for the new Segmented Control introduced in REAL Studio 2010 Release 4 that was release this week. Unfortunately, I stopped after about an hour after documenting bugs and becoming generally disgusted with it. What’s the point of doing a training video for something that is THAT jacked up and must be fixed (to be really usable) in a future release of REAL Studio? Why waste my time doing a video that I’ll have to do again?
I think it’s awesome that REAL Software creates REAL Studio and a handful of other projects using REAL Studio. But they don’t use it like we do in two different ways: Their testing process (and I wonder if they really have one sometimes) does not test the way a real world user creates projects. Their usage of RB for the IDE isn’t a real world example of what anyone is trying to use RB for. Saying “we build REAL Studio with REAL Studio” isn’t a valid metric for anyone except REAL Software.
I’m not an average REAL Studio user – I get that – I actually make my living off the product. I use it eight to ten hours a day on average of six days a week. When I do my testing, I start by creating a simple demonstration project showing the most basic usage of ‘X’ and then expand upon it by exercising most of the properties, methods and events. Most of these demonstration projects end up being reused in real world consulting projects and in the twenty-plus hours of training videos I have on my website.
I rarely waste my time and, in my opinion, the new features in REAL Studio 2010 Release 4 was a complete waste of my time. The documentation was late and incomplete and the new features have glaring bugs in them. If I can document several in an hour what does that tell you? Where were the example projects demonstrating the new features for Release 4? There were none.
Have you ever perused the Examples folder? There are a lot of example projects showing you how to use individual parts of the REALbasic framework. Depending upon which release you look at, some of the examples don’t even compile.
I also think it fair to say that most of the examples (that are working) are watered down to the point where they only show the most basic usage of a component. They are not complex examples and therefore don’t do most people much good when they get around to implementing it in their own projects. Most are not written with best practices in mind or how average people will use them. They were written with the intent of getting if off the developers, or documenters, plate as quickly as possible. Comments? Naming conventions? Defensive coding? Good luck.
REAL Software as a company does not create new cross-platform applications using their own product. They don’t see the day-to-day deficiencies that we do. They don’t feel my pain and that’s a problem because they’re trying to sell their product to people just like me – or at least that’s what they keep telling me.
I’m about ready to stop using REAL Studio for certain types of projects because they’ve lost control of the quality. Quality either matters or it does not. Decide which and let me know – I have better things to do until then.
Here’s my unsolicited advice for REAL Software: For every new release build a new project that demonstrates EVERY new feature and exercises it. Major changes to the framework get the same treatment. These projects should be good enough so that if there is missing documentation, the code tips or autocomplete doesn’t work (all real world examples, by the way), anyone can still figure it out from the code. It takes planning and a commitment and thinking about how real users will use the feature in Windows, Linux, Carbon and Cocoa applications.
Please, do this for upcoming Cocoa and Web Edition releases. If you could do that, I’d guarantee you’d find more bugs, earlier, and I wouldn’t have to spend my Saturday writing an opinion piece.
Conferences are always a good way to get together like-minded individuals and share ideas and to get energized. For those folks in Europe, the 2010 REAL Studio Conference is starting today (October 8th) in Koblenz, Germany. For more information, see http://www.realsoftware.de/realcon2010/
The 2011 REAL Studio Summit is taking place in Atlanta, Georgia on March 19th and 20th. ARBP announced early bird pricing this week of $250 with discounts available for the ARBP paid memberships. Early bird pricing will remain in effect until the end of November 2010. For more information see http://arbpmembers.org/real-studio-summit-2011.
The 2011 Summit is shaping up to be fun and interesting. REAL Software has committed to three sessions with at least one of them being devoted to the Web Edition which will be relatively new at that point. Another interesting twist is that one session will be about migrating from Visual FoxPro (yes, it’s still around and very much alive despite Microsoft trying to kill it off) to REAL Studio. Take a look at the 2011 Summit page for the tentative sessions so far.
The summit will also have the official meeting of ARBP where we will decide upon the future of the organization. All leadership positions are open and need to be filled.
I’ve already set the intention that I will not remain in a leadership role of ARBP. If nominated for anything I will respectfully decline. I helped birth ARBP with the help of a lot of good people and unfortunately we’ve lost a lot of those dedicated people due to various reasons. Unfortunately, the many responsibilities of the organization have fallen largely on me – especially in the past year. It’s essentially become a part-time job with no pay and while I love the organization it’s time to move on and it either lives or dies on its own. Not that I’ll go away, but I can’t sustain the same level of commitment that I have now.
REAL Studio released a point update to REALStudio this week and brought it up to version 3.2. The only bug fix listed is a Windows-only memory leak that affected various controls.
I know that the leak affects the StaticText control and the timer. The bug is simple to reproduce: add a StaticText control and a timer to the window and change the text in the timer.action event. Run it. That’s it.
The memory leak memory was so bad that one of my Windows apps was gobbling up tons of RAM to the point where the app was unusable. Though, to be honest, part of the huge memory leak I was experiencing was the fault of my networking code, but the StaticText and timer leaks weren’t helping matters any.
The bug was big and whether it was my ranting or enough customers complaining about it, RS fixed the leak and issued a 3.2 beta. Which I tested and the same day logged another memory leak. The original leaks were fixed but now just by putting window.refresh in the timer event caused a leak in the StaticText control. I actually logged it improperly because I wasn’t sure where the leak was and speculated on several different possibilities. The RS engineer in charge of it added a simpler example project into the Feedback report the same afternoon. So, obviously, they knew about the issue.
And yet, Release 3.2 went out the door with that known memory leak in place.
I’m not sure how I feel about it. I spent an awful lot of my own time (because I sure as hell can’t charge the client doing all this testing to fix a problem that’s not theirs). I provided timely feedback (less than 12 hours from the beta release) to test and document the bug and it was released anyway.
R3.2 is better, but it still has a major hole in it that may or may not be acceptable for my Windows builds. I’m very disappointed that R3.2 saw the light of day since it obviously wasn’t really fixed. In many ways I feel like this was a “Let’s shut Bob up and give him a new build.” I know that’s not the case or at least I hope not (not to mention that sounds sort of narcissistic).
I really am starting to question their commitment to the Windows environment given their current workload. Cocoa is late but is getting closer to reality all the time. The new Web Edition is generating lots of buzz and even though the Cocoa and Web Edition teams don’t overlap much, the keyword is ‘much’ so it means there is *some* distraction.
It’s been another miserable week of 12 hours days trying to debug my app AND Studio at the same time. So, yeah, it’s not been a pleasant one.
As a consultant I use the best tools available to me and my clients. One of those tools is the Formatted Text Control (FTC) from True North Software. Today they announced version 2 of their excellent text editor control.
FTC is one of those controls that I find indispensable and use a lot because of its power and flexibility. Because it’s done in 100% unencrypted REALbasic code you have complete control over how you use it. Need to do something that it doesn’t do? You can do it yourself if you have the patience for implementing your own changes.
FTC is big and powerful. It has around a hundred classes that let you implement a full-featured word-processor with very little work (literally drag and drop and maybe add ten lines of code). With a little bit of elbow-grease it’s very easy to create your own reports via code (perhaps I’ll write a little tutorial on that one of these days).
If you’re interested in learning how a control can be implemented in REALbasic using just a canvas this is excellent code to learn from. FTC does class inheritance well, is optimized, and the code is easy to follow.
Brendan Murphy, the creator of FTC, is very responsive to bug reports and feature requests. We’ve been users since the early days of development so you’ll see the BKeeney name in a few places in source code from bug reports and feature requests. It’s rare to see somebody share the credit so readily.
Version 2 has a number of welcome new features and enhancements. The first is that the alignment of the display when it’s in Page display mode. Before it was always flush left, but now you can center and right justify it. It’s a minor thing, but very high on my own wish list.
New search and replace functionality was added. You can do it either programmatically or interactively. There is also a new Replace All function.
You can now scroll to the selection which, as the name suggests, scrolls the display to the current selection (and presumably the insertion point).
A new KeyPress event was added that allows you to have more control over what characters can be inserted to the control. Since this is an event in the TextField and TextArea controls this is a welcome addition.
A new subclass was created from the FTC. The FTTextField is a replacement for the RB TextField control and has all of the advantages of the FTC. This means that the FTTextField can do spell-checking, undo, and the ability to read/write true Rich Text Format (RTF) files where as the RB TextArea is fairly limited in what it can do with RTF (no graphics).
Also new in the FTTextField is the ability to limit the number of characters in the control and the ability to use masks. Given that the RB mask property in the TextField is bad (perhaps sucks is a better word) this by itself might be worth the purchase price.
REAL Software quietly announced on the NUG yesterday that REAL Server is no longer part of its stable of products. They also said that current licenses for REAL Server will be honored by SQLabs, the once and current owner of the product.
This is not particularly good news for those that use REAL Server. REAL Server was a product that was heavily hyped for several years and is no longer available for sale and support through REAL Software.
The good news is that the product isn’t going away. REAL Server (or REAL SQL Server for those that have been around long enough) was purchased from SQLabs years ago and the primary developer, Marco Bambini, became a REAL Software employee and continued development of the product.
Marco and REAL Software parted ways several months ago. It was not until this week that REAL Software acknowledged his departure and its effect. It seems that as part of their separation deal, REAL Server will go back to SQLabs and be sold and supported by them. More info here.
REAL Server, for those that don’t know the history, was originally written by Marco Bambini of SQLabs. It was original called SQLite Server and it made SQLite database files networkable and multi-user.
This was pretty exciting at the time because even though SQLite databases were lightweight and easy-to-use they didn’t work very well across network drives, it had none of the mechanisms required to handle multiple users, and it had no foreign key constraints. From a certain perspective the acquisition and subsequent development of the product made sense from REAL Software’s perspective because it gave a migration path from the single-user SQLite database to an easy-to-use, install and administer database server.
Unfortunately, making SQLite into a database server proved to be difficult. Until very recently, an SQLite database knew nothing about foreign key constraints (and even now you have to go out of your way to use them). It also didn’t do any logic to handle concurrent users and all the headaches that go along with it (like record locking and user access control). The fact the REAL Server did do some of this was a testament to how much work they put into it. They fit the proverbial square peg into the proverbial round hole.
Unfortunately, REAL Server cost money and it was hard to compete against the MySQL and PostgreSQL database servers of the world which were mostly free. For a while the license of MySQL was a huge unknown mess (is it really any better now?) and REAL Server was marketed as a safe alternative to MySQL.
It’s hard to compete against free and well established database servers with hoards of developers contributing to it. Foreign key constraints and stored procedures and all sorts of other goodies were already in MySQL and PostgreSQL and both continued to evolve with new features while REAL Server stagnated.
At REAL World 2008 Geoff Perlmann showed off a demo of a new version of REAL Software that allowed for plugins, written in c, to become its new pseudo stored procedures. It was also supposed to show huge improvements in the number of concurrent users, have server side cursors, have client messaging and a host of other new features.
The demo was light on details but it was released later that year. The last official release of REAL Server was in 2009. However, many developers have found some of those new features to be buggy, and have stuck with the 2008 version. Meanwhile, REAL Server has been stuck in perpetual beta since then with no appreciable work. Now, users are stuck in limbo waiting for SQLabs to come up with a new release version.
This news sucks – especially if you had invested a lot of time and effort into REAL Server development in your projects. The lack of new versions in the past year should have been a good clue, though. Also, there were very few posts about REAL Server in the REAL Software forums.
I feel that the focus on the hobbyist developer blinds RS, sometimes, to what professional developers will gladly pay for. Don’t get me wrong, there are a LOT of hobbyist REAL Studio developers and that’s great, but it’s been my experience that the hobbyist developers can’t pay for much and REAL Studio was a cost (even as inexpensive as it was) that most couldn’t afford.
It was a losing battle from the start, really. It’s too bad that RS had to go through the painful realization that buying and building upon a product sometimes isn’t good enough. It was too expensive for hobbyist developers and it wasn’t powerful enough for the professional developers.
In a nutshell it never took off and that’s sad. It was a distraction and a drain on resources during a time when multiple developers were laid off due to the hard economic times. Cocoa is now running into its third year of development and one has to seriously wonder if the distraction of REAL Server, even if it was just one developer, cost them some serious development time. Certainly one could argue the money spent on development and marketing of REAL Server could have been better spent on other things.
Ultimately, the message this sends to the community is not a very good one. From now on, we, as users, will have to weigh the impact of relying upon any tool from the company since it may or may not be supported years from now. Granted, in this case, REAL Server is finding a new home and there will be support for the foreseeable future but what about the next new thing? Do we have to wonder about Linux or Web App support five years from now?
It’s not been a great week – even though it’s been a short week. I’ve now seen two separate bugs that are HUGE and affecting me for Windows. In REAL Studio Release 3.1 there is memory leak in the Timer Class and in the StaticText class. The end result is that my app, in Windows, will eventually chew up all available memory and bog the entire machine down to the point of being unusable.
Not good at any time, but this mean that both 3 and 3.1 are not usable for me, at least for Windows builds. R 3 has some issues and a memory leak as well. Thankfully, the leak is not as bad. I would go back to R 2.1 but since *that* release also has a nasty Windows bug I can’t go back to it. Dare I go back to R 2?
Initial indications are that RS will not be issuing an interim 3.2 release, however. This is why I think their Rapid Release Model stinks. I’ve got two bugs that keep me from using the latest and greatest release and now have to wait to get a fix.
Your plan runs out in the next 60 days or so? Sorry. You’re S.O.L. It might be great for RS but the Rapid Release Model is becoming the Rapid Bug Model for me. Pretty soon, it’s going to start costing me clients.
———-
A couple people have asked me what I think about Apple changing their stance on letting 3rd party development tools for developing iOS apps and what that means for REAL Software. Meh.
Really, there are so many items RS has to get done before thinking about iOS that it’s not even a concern right now. The only thing that would concern me is if they decided to jump both feet first and devote a lot of resources to it. Cocoa has taken way longer than anyone ever dreamed of (I feel that personnel changes have bit them hard on that one) and now the highly anticipated Web Edition will distract them too.
Don’t get me wrong, I’m looking forward to the Web Edition. I think being able to leverage all my RB knowledge for iOS apps is a great idea too. But, as they say in Missouri, “Show Me!” – I’ll get excited when I see them and can work with them and keep my business in the black.
First, let me get this out of the way: I am not a web developer. My plate is more than full enough developing desktop applications and while I’d *like* to do some web apps, it’s just not in my realm of the probable at this point in my life. However, I am pretty good at developing REALbasic applications that work well on Mac OS X and Windows (and throw the occasional Linux app in there too).
REAL Software announced today a new version of REAL Studio, called Web Edition, that will be released some time this Fall. Internally, they called this product Barracuda. If you know any history about REAL Software, they had an internal product named Swordfish that they announced at their annual developers conference in 2005. It was never released because it was already obsolete soon after they announced it due to a variety of technologies like AJAX and JAVA and a number of other technologies. So call this completely rewritten version the “Son of Swordfish”.
I spent three hours playing with an alpha build this weekend and my first impression of the product is good. Since it’s an alpha build it has plenty of bugs but it is an interesting twist on REAL Studio and REALbasic. This has the potential of being the first Rapid Application Development environment for web apps that doesn’t require an expensive server as these apps will run on any Apache server or web server capable of FastCGI (not all commercial hosts enable FastCGI on shared servers).
Existing users of REAL Studio will be instantly familiar with the editors and know how to get around. Since web apps are unlike desktop apps in many ways, there are a number of new objects, classes, and controls that are for web apps only. There are also some things, like the MsgBox function, that did not work for me but will probably work when it’s released.
Instead of the regular Application object, every REAL Studio web app has a new WebApplication object that handles the open, close and unhanded exception events. New to the web app is the WebSession object which represents each user that is connected to your application. It has Open, Close and Reloaded events which, as you can imagine, are similar to what you might do in the Application object in the desktop version since a desktop app supports one user at a time.
Instead of creating windows, you create web pages and you edit them in the web page editor. It is much like the current window editor but has a new set of controls and new features to go along with it.
One of the first new features you’ll notice is the ability to do in-line editing. There is a little editor icon to the right of most controls that when selected, brings up an editor for that control and masks out the other controls. For some controls, like buttons, text fields and so on it simply changes the text you see on screen. For more complex controls like the listbox, for example, you can add column headings and add default data into the listbox.
In some respects some of these features remind me of how ActiveX controls in Visual Basic 6 used to have their own editor and UI and for the most complex of controls this will be welcome as editing them through the properties list can be tedious. For the simpler controls (like the button, label, etc) this new inline editor does the same thing as simply selecting the control and starting to type.
The page editor has tweaks on features that are better than the current Window editor such as visually aligning controls and showing spacing differently. There are also a number of new controls that are pretty common in web apps today: Link which is a label that when pressed opens the browser to a new page; Search Fields which is a rounded TextField that keeps track of last values held; Segmented Button which is a row of buttons that can act like either radio buttons or check boxes.
There are a number of controls that have changed as well. Pushbuttons are now WebButtons and Checkboxes are WebCheckboxes but act pretty much the same. The StaticText object has been renamed to the WebLabel (which makes more sense to many developers coming from other languages). Radio Buttons are no longer individual controls – they are now part of a group and you can specify their dimensions like a listbox (number of columns and rows). I’m actually on the fence on this one since I see the value in it but could also see it biting me depending upon the complexity of the user interface in the project.
The first release will not come with a proper tab control, unfortunately. This is disappointing, but you can easily overcome this limitation with a Segment button and using Container Controls. Just like with the desktop app, I think Container Controls are incredibly powerful, and is a useful way to make complex, reusable ‘window-like’ objects.
Perhaps one of the bigger changes is the removal of the Canvas object. This was done, I was told, because HTML5 has a canvas object and REAL Software did not want any confusion. Instead we have the ImageView object which can accomplish many of the same things using its Picture property (the graphics object is gone). The canvas object may return at some point, however.
One huge change is that in none of the controls or windows can you control the text characteristics or background colors you’re used to expecting in a desktop app. For that, we now have Styles. Adding a style is just like adding a new class or anything other object in REAL Studio and when you edit a style you have the ability to change the properties of Normal, Hover, Pressed, and Visited objects (this includes pages). There, you can control the text properties, border, shadows, padding, corner radii, and opacity.
As you can imagine, this leads to some very interesting interactions that take very little code. For example, you can create buttons that change color when you hover over them, or change opacity once you’ve clicked on them. I suspect that this will be a huge deal in the long run as it makes very complex interfaces very simple.
Since there are a ton of things you could do with a web app and no possible way for REAL Software to cover them all, they have a virtual control called PageSource that lets you add pure HTML code, JavaScript, and others, and can be placed in any web page. It has two properties, the code itself and the location. You can place it in the Header, Before Content, or After Content. I imagine that just like for plugins for desktop applications, there could be a market for HTML components for REAL Software web apps.
Placing and dealing with the code behind the objects is just like a desktop application. In fact, it’s the same code for the most part. Where things start to diverge is with dialogs. In desktop applications you create a window and change it’s super to modal dialog or similar, and call it via code. This was flexible and convenient but created a new window. Many users have popup windows turned off so this won’t work.
To compensate, REAL Software created a web dialog class that doesn’t create a new window, it just shows up on the current window using some nifty AJAX. Since the standard MsgBox method did not work in this alpha build I ended up creating my own web dialog and adding it to the page. After you add it, it is displayed in a new list at the bottom of the window and can be access there. Otherwise it acts similarly to how dialogs work now.
Debugging an app is easy as well. Simply hit Run in the IDE and it compiles and runs the web app on the local web server. It responds to break points and exceptions just like a desktop app and and allows you to interrogate application variables in the debugger.
I’m not sure if web apps will understand the concept of Reports in the first release or not. If you need to display a report to the user, you could probably accomplish the same thing with a listbox that covers the entire page.
Currently, REAL Studio supports two types of builds. The first is HTTP and the second is FastCGI. FastCGI should be more efficient, but might not be for everyone if you’re on a commercial hosting service since many do not support FastCGI.
REAL Studio Web Edition apps work with Safari, FireFox, Chrome and Internet Explorer. How far back this compatibility goes I’m not sure of at this point. If you find a limitation, you can use the functions in the Session object to get the browser type, operating system, platform, etc and give corresponding messages.
The Session object also keeps track of the page state so your active web pages won’t be forgotten during a session. This means that each page is ‘remembered’ which is a very nice feature. So if you have a Customer page and an Invoice page and the user reloads the page or closes it and returns before the session ends it will load exactly where the user left off. This is another one of the main features that I’ll like to see in action on a complex web app.
I spent less than a half hour converting a very small calculator application I had originally written as a desktop app. I spent more time logging the minor bugs (I did say it was an alpha build, right?) I found than I actually did writing the web app. I have no idea how long it would take to accomplish the same thing in php, Javascript, Ruby on Rails, or ASP.NET, but I suspect the answer is longer. I’ll be curious to get a true web developers impression.
The one big question that remains is how easy it will be to deploy and install REAL Studio web apps on your server. I looked up some documentation on my commercial host on how to install FastCGI apps and it did not appear to be for the feint of heart as it required going to the command line on the server. At this point I do not think there is an option for Single-Click-to-Install.
The Web Edition will become part of the Enterprise Edition of REAL Studio and also as a standalone version for those interested only in web apps. This addition to the Enterprise Edition really makes it worthy of the Enterprise moniker now. The web app addition is scheduled to be released sometime this Fall. With REAL Software’s rapid release plan that could mean either Release 4 or 5.
What do you think about this announcement? Is your curiosity piqued?
I don’t have a whole lot to add because I agree with most of his suggestions. I do have one bone to pick with the use of ‘Enterprise’ as the top of the line REAL Studio product. REAL Studio isn’t big in the ‘Enterprise’ market and naming it such doesn’t give you an automatic ticket into it. If anything, it limits the current Pro owners who say, “I’m not an enterprise developer so why should I pony up the money?” Perhaps, ‘Premier’ or ‘Ultimate’ might have been a better term.
Thinking back over the years at all the of the ‘hot’ programming languages, they’ve all had interesting names. Java, Python, Perl, Ruby on Rails all have one thing in common: They don’t say a damn thing about what they are or do. But, boy, do the names stick with you and sound cool when you talk to a group of people. ‘REALbasic’ not so much. Like BASIC would be anything but real?
Enough griping. Changing the name of the product or company is a huge gamble it’s not one to be done lightly. One would hope that a name change with the product could invoke images of coolness, power, imagination, something hidden slightly out of view, and something mysterious enough for folks to check it out just because it sounds like those things.
Maybe something that gives you a hint of the cross-platform capabilities of what it can do. How does “Crossbow” sound? I can see the marketing campaigns now. “Hit your cross-platform targets with Crossbow!”, “Crossbow is powerful enough for three platforms, but easy-enough for the mere mortal to use.” The IDE icon changes to a Crossbow or Arrow sticking out of a target. “Introducing Crossbow by REAL Software” sounds better (to me) then saying, “Introducing REAL Studio by REAL Software”. Too many ‘reals’ in there for my taste.
Anyway, random thoughts on a Friday. What say you?
