How’s Your Xojo Mojo?

Xojo was released a week ago.  For those of us that were in the beta program (and even earlier with the alpha program) it seems like we’ve been using Xojo forever.  I have plenty of my own opinions and I can take some small satisfaction for saying, “I told you so” in some areas in regards to the new UI.

There are plenty of things in Xojo that I dislike.  The use of vertical space in the Inspector is atrocious.  The lack of keyboard shortcuts is annoying.  Getting lost in the Navigator makes me less efficient.  The inconsistent use of checkboxes vs sliders is disappointing considering this release was put on hold for a year.  Note that I didn’t say that any of these issues were show stoppers.

For me, the IDE has crashed some but not to the point where I want to put my fist through the screen.  I’ve gotten the Navigator so lost that it doesn’t redraw properly but a simple Xojo restart seems to fix that.  There have been times when the focus is somewhere other than where I want it and a Duplicate command creates a duplicate of something else entirely and sometimes it takes me a day to find the duplicates because they’re hidden in the Navigator.  Again, these are annoyances and not show stoppers.

I know that some Windows users are very unhappy with the new user interface and that for some Windows users the IDE is horribly slow and the flicker is bad.  I’ve not investigated this in any great detail but it seems to be related to GPU power and OS on the end users computer.

While there are plenty of things to dislike there are also things that I just use.  Xojo is usable for me and my team and I’ve spent a considerable amount of time using it (roughly 80% of my time) the past couple of weeks.  For me, the Cocoa framework seems to be solid and while some things are different I expected a certainly level of incompatibility.  It is after all a new framework that, while close to Carbon, is still different enough to cause some heartburn.  Really, the only major difference that I’ve seen is that using Threads is a pain now.  Software development isn’t always pretty or easy but Xojo has done a good job of making it easier.

I am looking forward to the future releases to see how they combat some of our biggest gripes.  A few changes can’t come soon enough but bottom line, for me anyway, is that I can use Xojo for consulting projects.  My fallback is always to go back to Real Studio but I don’t think I will need to.  The few times I’ve gone back into Real Studio I have discovered that it looks ‘strange’ now.  So give Xojo a chance.  It tends to grown you.

So what are your thoughts?  Do you like it, love it, hate it?  And why?

PS.  Let’s keep the remarks civil.  I don’t like it when users make personal attacks on me and my team in tech support.  I’d like to keep the comments respectful.  I’m friends with much of the Xojo team and I know they put in a ton of work for this release.  I for one will cut them some slack and I hope you will too.

16 thoughts on “How’s Your Xojo Mojo?

  1. Overall I believe it’s a good way forward. Not sure I fully like the Navigator yet, but I can see where they’re coming from.

    My biggest issue is real-estate. Although I have a good size screen at home, my laptop is now a Windows 8 1366×768 (since my Macbook Pro logic board fried) and I found on a long flight that it was just painful with so much screen space consumed by the navigator, inspector and the incredibly large uncustomizable toolbar! In fact it felt like I was editing on a postage stamp.

    I admit I was dismayed that no one at Xojo must have tested/worked on that type of screen rez, even Delphi/Visual Express makes it usable.

    However, I tend to subscribe to the “one step back, two steps forward” theory so I’m hoping over time it will wash out as resources get allocated to move the issues forward.

    I just find the concept of XOJO usable for what I need. I’ve already sailed on a different boat for iOS/Android when I need it (not that often). For desktop work, still more than happy. No deep reason to change right now.

    • I believe a dot update is in the works. It’s only been a week since release so I would expect it to hit beta in another couple of weeks? I don’t think they want to get into the process of issuing dot releases every week.

  2. Overall, I’ve been very happy with the release.

    I confess I was not optimistic, and I think I let my experiences with the early releases of the last IDE rewrite color my opinions.

    I haven’t had any crashes (OS X.8.3).

    I think Xojo should be proud of what they’ve accomplished.

  3. Sigh….

    I first need a bigger monitor. Then I’ll change from RS2011r4 to Xojo because I urgently need some of the Cocoa fixes. I still think that nobody at Xojo’s really thought about actually working with Xojo. This needs major re-factoring.

  4. There are a lot of details I don’t understand. Here are two examples:

    Do a search, set the focus to the search’s result list, and press Cmd-A. The source code above is selected instead of all the rows in the search’s result list.

    When you double click an item in the Navigator a dropdown menu appears in the title bar of the Navigator. Why is this menu only showing the main project, shouldn’t it show the hierarchy between the item you have double-clicked on and the main project (like the “Path” dropdown menu in the toolbar of the Mac OS X Finder).

    Are these bugs, is it GUI design gone wrong, or intended?

    In general, I don’t think it is a bad product though. But after using Xojo for a week, my impression (or concern) is, that they try to go the “Apple” way. In the last years Apple has more or less given up on producing goods intended to be purchased by companies and IT professionals (XServe, Macbook 17 inch, anti-glare screens, Final Cut Server, etc.), or – in a similar sense – they are re-targeting products like Mac OS X Server to hobbyists and semi-pros.

    Large companies can do that, small companies – in my opinion – have to do the opposite, so in my opinion Xojo Inc. has a strategy problem: trying to “go broad” instead of excelling with an awesome niche product, since professionals will always pay money for that quality.

    RB is a cross-platform development tool. Which – in my view – automatically means that the two fields where a product can beat its competitors are the wrapper of the OS (file system, threads, and much more) and the GUI library. And the GUI part is – IMHO – the weakest part of RB. The evolution of Windows, iOS, Mac OS X is fast, but no new controls are added (Splitter). Important controls are not native (listbox). Oddities in the API are not replaced by better solutions (ContainerControl/EmbeddedWindowControl). If you want a really decent looking product you need to use a lot of declares or spend more money (plugins) or develop a plugin yourself (and you still can’t use your favorite language for that).

    The decent looking GUI is the part where you loose all the time you saved on rapidly developing the first version of your software. In the end – if you know the programming languages – you are maybe better off programming in C, C++, and Objective C. Interestingly my Objective C and especially my Objective C Runtime knowledge drastically improved through ameliorating the GUI of my software.

    For hobbyist and semi-pros Xojo is too expensive (not for what it is, but compared to the competitors like Qt, Java, wxWidgets, etc.), so it might not attract a lot of new customers.

    And the name Xojo can’t hide that the programming language is Basic. I really don’t understand, why at Xojo Inc. they think that somebody would overcome his dislike of the Basic language just because of the name change. I think, Basic-haters have a built-in Dim-barrier…

    P.S.: Bob, this is one hell of a Notify-me-of-followup-comments checkbos directly above this text field – why not make a iOS-like switch…

  5. I think I start with the things that I think are good or I had a good experience with. First thing that comes to my mind is the auto completion. The inspector wasn’t such an issue for me. I would say it’s easier to pick what I need for example the Locking Section. What I find disturbing is that pressing enter after editing a value doesn’t set it or only if you use the left enter key. It just makes a annoying “ding”

    Also I do agree that the Navigator isn’t that handy. I also got lost in it. Maybe I just need to get used to it or maybe it is actually a bad thing. Anyway I asked myself what would be better to handle all those things that the navigator holds. And I don’t know one.

  6. Marco Rebsamen :
    Also I do agree that the Navigator isn’t that handy. I also got lost in it. Maybe I just need to get used to it or maybe it is actually a bad thing. Anyway I asked myself what would be better to handle all those things that the navigator holds. And I don’t know one.

    This is not a issue of you getting use to it, but rather a problem of REALLY poor design. It is simply not scalable. When you start opening up more items the more likely you are to “get lost” in the sea of items. Also since the navigator now mixes all the types (folders, classes, methods, properties, etc.) in one big long list, it becomes hard to discern where one class ends and the next one starts. This can lead users to modify wrong items since they didn’t know where they are which is really bad! At the minimum it forces users to exercise a significant amount more brain power to make sure they are where they think they are and again this is really bad.

    The fact that you can double click on an item to open up a new tab tells me that they recognized this problem of scalability and chose to toss usability in the garbage can. This makes no sense to me because the usability issues in the Navigator are so glaringly obvious! Was it the twinkle of the “new and shiny” that blinded them as they designed the Navigator?

    The Navigator needs to be completely scraped and the previos product-tab metaphor restored. The Navigator is a fundamental component of the IDE which the rest of the IDE depends on and thus I suspect will be much harder for them to undo. If they continue to enhance the Navigator in the next release, then you had better learn to live with it or find a better solution for your needs. I feel sorry professionals like Bob who spend all day in front of this IDE because it is like chewing on 60 grit sandpaper.

  7. @Brendan Murphy
    Funny you bring this up. I was thinking about this just yesterday and remarked on the very things you hate about the Navigator. Too much data and not enough visual difference and irrelevant data based on the context at hand.

    I don’t know if it needs to be completely redesigned, but if the Navigator was changed so that it only showed objects like the old Project Manager it would solve most of it’s usability issues. I see no reason to show source code level items (methods, constants, properties, etc) unless I’m actually in the Code Editor.

  8. @Brendan Murphy
    And yes, I agree that they felt it was ‘new and shiny’ and stayed with it regardless of negative feedback. As someone who used it early I feel I am justified in saying, “Told you so.”

  9. You know the people a Xojo are reading this comment section and you got to know these comments got to sting a bit. The question is what will they do? I see the following basic choices…

    – Do nothing.
    – Brush these comments off as flaky responses and continue doing what they are doing.
    – Try to make a compromise and attempt to enhance the Navigator to a cross between the old and new.
    – Listen to what has been said and scrap the Navigator.

    Past history has shown that they can equally dig in their heels, or listen and change their direction. What I mean is that once they have made up their mind on certain things it doesn’t matter what the reality is, there is no way to change their minds. But we have also seen them change directions before if enough people complained. So it is either feast or famine with them. Which way will they will go with the Navigator, I do not know. If in the beta period they heard a bunch negative feedback about the Navigator and they still chose to go with its current form, then there is little hope of changing their minds since they think they are right. This reminds me of Microsoft’s Windows 8 where they married together two diametrically opposed styles of computing (modern UI and the desktop) and ended up with confused miss-mash of a user experience. Microsoft responded to their critics by say they are not being stubborn but principled in the changes they are making. That is corporate speak for, “we don’t think you are right, but we will throw you a bone to make you slightly happier.” In other words they are trying save face without admitting that they blew it. The same kind of scenario exists here in what will Xojo do. The best course of action is to dump the Navigator and begin again with the project-tab metaphor. “Years” ago I suggested to them that they create “working set” so end users could quickly open a set of files from a project. You could have a working set to open up your database related files and another set to open UI related files etc. If they were trying enhance tab management, that would of done the trick. Imagine a simple popup menu that allows you to switch between working sets? How much would of that “increased” productivity? There is the old saying, one step forward and two steps back. In the case of the Navigator it is no steps forward and three steps back.

    So you fine folks at Xojo, please take an objective look at the productivity cost of the Navigator and you will see that it is an inferior solution because of the scalability issue. If you continue with the Navigator, it is like a huge boat anchor to the product.

  10. Some thoughts on the Navigator.

    I think it’s obvious that the inspiration for the Xojo IDE was Xcode or something similar. While Xcode and Xojo projects are different beasts, it might be helpful to look to see how Xcode handles things.

    In Xcode the xib files (containing graphic elements of the UI) are listed in the Navigator. Click on a xib file and the Editor changes to Interface Builder — just as in Xojo. BUT as part of the Interface Builder Editor, a Dock appears next to the Navigator. This is where the bindings for individual elements live. It can display elements as simple icons or as a hierarchal list.

    This uses more horizontal space, but relieves vertical pressure on the Navigator. And in our wide screen world, we often have more horizontal space than vertical.

    Translating that into Xojo a second Navigator pane could open for graphic elements in the Navigator — windows, containers, toolbars, menus, etc. And inside THIS second Navigator would live the elements of those items — including the event lists of those items.

    This would relegate “big” things to the main Navigator — windows, modules, menu bars, etc. And small things to the mini Navigator — buttons, labels, menu items — and all their events.

    For those not familiar with Xcode, I’m going to try to embed an image. I don’t know if this will work. So if not the image can be found at


  11. Some thoughts on vertical space in the Properties Pane.

    Adding keyboard navigation would go a LONG way to fixing this. Being able to tab through the items, with the pane automatically scrolling as necessary, would make it much more bearable.

    Although reducing the vertical space is still needed to allow checking settings at a glance (without scrolling).

  12. Putting aside the Cocoa and general framework enhancements… I imagine the Navigator is one of the elements that consumed a larger percentage of development time. I mean its quite an interesting control that is doing quite a bit. It is very aesthetically pleasing and on the surface (screenshots) looks quite nice. It’s only after you start using it you realize how terrible of an idea it was.

    So for the powers to be to swallow the humility pill and realize they are better control designers than usability experts… hmm I dunno. Especially with the time/money energy invested. Had they just cleaned up the toolbar, libraries and inspectors and kept the project window and tabs the IDE could have been done a long time ago.

    What I think took awhile are:

    1. Navigator
    2. Cocoa fixes necessary to make Navigator
    3. Xojo cloud hosting integration which seems to still not be fully fleshed out
    4. Complete change in the licensing system

    I think if they had just done #4 we would have been using Xojo this time last year and they’d be better off for it. There is nothing wrong with incremental changes.

  13. Brendan Murphy :
    When you start opening up more items the more likely you are to “get lost” in the sea of items. Also since the navigator now mixes all the types (folders, classes, methods, properties, etc.) in one big long list, it becomes hard to discern where one class ends and the next one starts.

    Yes, and I repeat what I already posted on the Xojo Forum:

    I need a reliable hook, some kind of anchor, where I quickly can go back to and find those objects that I am working on. Without scrolling.

    So I probably would do three things:

    1.) Keep the root of a tab locked (I don’t wish to see ‘multiple selection’ any more)
    2.) Create the option to save and load different sets of tabs
    3.) Create the option to save and load various finder views where the root of the tree remains locked

    Now I have hundreds of items in the navigation tree and every now and then the root node changes and I have to scroll again. Now the tabs may change in a similar way plus the number of visible tabs is limited.

    But sometimes I want to work on everything which is database related. Sometimes I’m working on UI elements. Sometimes I’m working on business logic. Sometimes I’m working with automation classes – and all of these are clearly separated in my project. So when I concentrate on one area, I do not want to scroll through all those other objects which then are not of interest to me.

  14. I’ve deliberately waited a few weeks before saying anything about Xojo as I wanted to give it at least a few days of solid work before forming an opinion.

    First off, let me say congratulations to the developers at Xojo, it’s clear a LOT of work has gone into this and it’s mindblowing to me that this is written in Xojo – truly an example of what can be achieved. I am very impressed with what you can do.

    My general impression of the new IDE is ‘fresh’ and in many ways a work of art.

    I go back to RS and it looks rather 90s. Unfortunately though, along with the fresh face has come a few significant blemishes. The interface is very busy. Whilst I never have issues using RS on a 22″ monitor, I’m forever scrolling in Xojo. I realise panes can be closed and resized but I’m constantly fiddling to try and get things right. I know it will sound minor but I also find it incredibly annoying the resize widgets are on the end of each pane rather than in the centre. The ‘crampiness’ is exacerbated by not being able to drag a window around in the IDE – you have to scroll to see it all which is much slower than a simple drag.

    At the bottom of the window we have the pane displaying search results and errors. I’m yet to come to grips with the Search results in this pane – in fact I’ll go as far as saying it’s a pain… I much prefer the old way where a new tab would open with a full window of results. The same goes for errors – too much scrolling or resizing required. IMHO this *really* needs a preference to “Display search/errors/messages in a new tab” option. I’d like to see the pane diappear.

    For whatever reason I seem to be constantly getting lost in the Navigator. I’m not a fan of the hierarchical display of project items – I just don’t see the need when you can simply double-click an item and see only the relevant items – it’s redundant clutter which can get very messy, very quickly. I know Bob spoke of this in his review and I can certainly see his point – it’s just a bit drunken on its feet. There are a few navigational bugs relating to naming conflicts with folders but I think it goes deeper. I double clicked on a listbox control yesterday and was magically transported to a totally unrelated method?? Restarting fixed the problem temporarily but I’ve seen it again today. Consider this a rousing vote for the old Project tab. The new Navigator is a significant step backward in usability, despite looking quite pleasant. It really bothers me that so much work has gone into it and it works so badly, I really wish it worked well.

    Like the Navigator, the Inspector palette *looks* really nice but is WAY less functional than the old one. Due to the physical size of the widgets it has to be scrolled a lot to get to all the properties. It’s a shame to see form overriding function as it takes much more real estate to do the same job.

    As far as the Library is concerned I’m a little ‘meh’ about it. It’s aesthetically pleasing and does the job so I guess that’s all it needs to do. To be honest, I would prefer if the Inspector looked more like the Library so we could have a more condensed view of the properties.

    There’s a bug in the tabbed interface where Xojo creates a new tab every time you double click a control. Hopefully this will soon return to the behaviour where an existing tab would be selected instead of creating a new one.

    I’m still not used to having to enter control events. I add a control and just expect all the events to be there – then I have to work out which events I may or may not need – just wasted time – I much preferred them all being available and I can’t see good reason for the behaviour changing.

    Sadly there’s nothing that stands out for me as a great improvement. All my current apps were building well in Cocoa but I trust there are improvements there. The IDE was really the big thing in this release and it hasn’t been a forward step for me. I’m trying really hard to like Xojo but for now I’m sticking with RS 2012 2.1. I sincerely hope some of the weird things are fixed soon as I’d like to just have one version of things (and we’ve renewed for 2 years). To remain productive I am currently doing development in RS 2.1 then duplicating the file, opening in Xojo and building to get any potential Cocoa benefits.

Comments are closed.