BKS Spell Checker 1.0.2

picBKS_SpellCheckerWe released a new version of our Mac/Windows spell checker plugin today.  Version 1.0.2 works better with foreign language Hunspell dictionaries that are in different encodings.

The Spell Checker plugin has two different spell checking modes.  In the first mode it  works with the native spelling dictionaries on each platform.  On all versions of Mac OS X (that Xojo supports) and Windows 8 and above it uses the built-in spell checker dictionaries.  If you can’t, or don’t want to, use the native dictionaries you can use the Hunspell dictionaries.  There are hundreds of Hunspell dictionaries available for use in a variety of languages and speciality industries.

There is no Linux version at this point due to lack of interest.

More information, including downloadable demo, pricing, and usage is available at http://www.bkeeney.com/allproducts/bks-spell-checker-plugin-for-xojo/

LiveCode vs Xojo

I have been a Xojo developer for many years and I make a decent living at it.  That doesn’t mean, however, that I don’t look around at other development environments every now and then.  I do this because it makes good business sense to keep my options open.  This week I looked at LiveCode after a reader asked me to.

LiveCode (formerly called “Revolution”) is a unique development environment that has been around since 2001.  It was inspired by HyperCard and due to its lineage it uses a Card and Stack metaphor to represent windows, objects, and applications.  To put it more in Xojo terms you can think of a window as being a Card and the entire application as a Stack (of cards).  Dialogs and other objects can then be sub-stacks.  LiveCode can make Mac OS X, Windows, and Linux desktop applications, cgi-like web apps, and mobile apps for iOS and Android.

Its scripting is a natural English-like programming language that presumably makes it easy for casual programmers to get started.  Another interesting feature is that there is very little difference between ‘development mode’ and ‘debugging mode’ and switching between the two is literally just a button.  This means that you can run LiveCode commands practically at any time without the need to compile the application first.

The IDE has a variety of windows.  The Application Browser shows you all of the objects in the stack and lets you open each card into an editor.  The editors let you put controls on the Card (layout) and each card and UI object has a number of Messages that are similar to Xojo events.  LiveCode does not have an all-in-one window like most other IDE’s.  At first, I found the individual windows to be refreshing but after I while I found that I was fighting with background application windows.  I’m sure this is something that becomes more natural with usage but I had issues with it.  I’ve always wondered if Xojo’s all-in-one window IDE approach was really the ‘best’ approach to a development environment and now I see that I prefer it as it eliminates the distractions of other windows.  Also, Eclipse, Visual Studio, Xcode and Xojo all have all-in-one IDE’s so I this it safe to assume that most developers are comfortable with this style.  You may find LiveCode strange if coming from an all-in-one IDE.

The LiveCode scripting language definitely takes some time to get used to.  The natural English syntax seems inviting but after 30+ years of coding in various languages I found it frustrating.  It’s wordy and not exceptionally compact in its meaning.  If you don’t already have any programming experience this might be good for you.  If you’re coming from a different language you might be as frustrated as I was.

Xojo events are relatively easy to find and implement.  You simply right-click on an object either in the Navigator or in the Layout Editor and add Events to the object and it’s added into the code waiting for you to add your own code to it.  The object messages in LiveCode are not so easy to figure out, in my opinion.  To figure out the events I had to go into the documentation (which was decent, in my opinion), and had to look them up and then type them into the Script Editor.  I’m sure with a little time and practice I would pick up the messages that I use most often, but it is a hindrance to picking up the language.

LiveCode Dictionary

LiveCode API Dictionary

 

The Xojo Code Editor has a pretty good auto complete.  Auto complete means that when you start typing, say “SQLite”, and if there are either language keyword matches or variable matches the eclipses (…) is shown and if you hit the tab key a list of available properties and methods are shown to you in their proper context.  This makes discoverability much easier.  LiveCode has no auto complete in their Script Editor which means you have to look up the commands before you start typing and you won’t know if they’re correct until you run the project.

LiveCode has objects but they don’t have the same Object Oriented nature as Xojo.  In Xojo you create an instance of the object and then get/set a property or call a method using the dot notation.  Thus opening a database in Xojo means creating a new instance of the Database, setting a FolderItem property on that object.  Then calling the CreateDatabaseFile method on that same object and it returns a true or false to indicate success or failure.  All of that revolving around the same object (database).  The same thing in LiveCode requires less coding steps but there is no dot notation and it’s definitely more procedure driven.  Each method is its own call – not part of an object – and means that you’ll spend more time looking at documentation to discover them.  I feel that Xojo’s discoverability is superior to LiveCode.

LiveCode is not a strictly typecast language meaning you can use a variable anywhere at any time.  This means that writing scripts can be very quick but it also means that introducing errors is easy and with larger projects it might be hard to find errors.  Xojo, on the other hand, is strictly typecast and the compiler will tell you if a variable is not defined or if you try to put the wrong type of data into a variable.  There are plenty of other languages out there that don’t require variable type declarations but I never have spent much time with them.  If you’re used to them it’s probably no big deal but I tend to like the compiler to warn me early and often of any potential issues.  Another little thing about the language is that to assign a value to a variable using the Put command rather than an equal (=) sign.  In LiveCode you would say:

put “ABC” into myStringVariable

In Xojo this same thing would be

dim myStringVariable as String = “ABC”

LiveCode Create DB

Creating an SQLite Database File using LiveCode

Xojo Create Db

Creating an SQLite Database File using Xojo

 

One of the major drawbacks that I discovered early on was that LiveCode does not make native looking applications.  The good news is that PushButtons look the same on each platform (no mean feat) but it also means that those Pushbuttons don’t look native on any platform.  There are commercial plugins available to make LiveCode applications look native on each platform.  I don’t believe that the plugins are using native controls either so this means that an OS update might ‘break’ the look of an application until those plugins are updated.

LiveCode Mac app

LiveCode App running in Mac OS X

LiveCode Ubuntu App

LiveCode App running in Ubuntu

LiveCode Win8

LiveCode App running Windows 8

 

Xojo is not perfect in this regard as not all of its controls are native on each platform either.  It does, however, use them whenever possible.  Another drawback to Xojo is that control features are often times the lowest common denominator between Mac, Windows, and Linux for desktop platforms.  This is more for feature parity than any malfeasance on their part.  Xojo web apps and iOS apps use native controls.

LiveCode, like Xojo, lets you create external libraries using C++.  LiveCode calls these Externals while Xojo calls them plugins.  It appears that there is an active community of developers and an active 3rd party development community for LiveCode.

Unlike Xojo, LiveCode comes in two different varieties:  Community Edition and Commercial.  The Community Edition is open sourced and free but limits you to open source and GPL applications.  If you are interested in LiveCode this is where I’d recommend that you start.

There are four different types of commercial LiveCode licenses.  The Indy Commercial license costs $299/year per seat and lets you do closed source and royalty free commercial apps with a $500k revenue limit (how this is enforced I have no idea).  The Business license costs $999/year/seat and eliminates the revenue limit.  The Pro license $1,999/year/seat and gives you more personalized service and a Premium license is $10,000/year for 3 seats and gives you priority support, use of their test suite, extensions, priority features (whatever that means) and a LiveCode conference ticket.

LiveCode also has a membership program that costs $99/year ($25/year for students) and gives you exclusive membership benefits and helps supports the continued development of the platform.  You also get access to over 100 training videos and access to the LiveCode Conference simulcast.

What I Liked About LiveCode

I found the LiveCode Start Center to be clean and uncluttered and useful.  It has four main areas, Projects that shows your recent projects, Getting Started that has handy links to the some beginners videos and guides, Resources that takes you to tutorials, sample stacks, the community forum and their API dictionary, and finally they have a Sample Projects list that has a sample projects in it.

The LiveCode website also does an excellent job of pointing out 3rd party commercial and non-commercial extensions and what they can do for the developer.  They also allow user reviews of the extensions so it makes it easier to make a purchase decision.  I have no idea what it takes to get listed on their website or if LiveCode takes a cut of the revenue but it’s something I wish Xojo would do a better job of helping their 3rd party developers market.

I also found it refreshing that their API documentation allowed user comments.  I really wish Xojo would do something similar because I feel that we, the user community, could add some really useful comments to the documentation.  While I like the Xojo documentation I feel it might be better served by opening it up a bit (with moderation).

LiveCode does deploy for Android which might be a huge bonus for some.  Assuming I could get a UI that looks native it might be the one thing that would make me look at LiveCode with any seriousness if a client asks for Android deployment.

Finally, the fact that part of LiveCode is open sourced is interesting.  They successfully ran a KickStarter campaign to open source the product in 2013 and successfully did a campaign on their own website to fund HTML5 web deployment in 2014.  I don’t know about anyone else but I would help fund certain items for Xojo development even if wasn’t open sourced (perhaps a better grid control?).

What I Disliked About LiveCode

If you’re coming from C++, Java, or any object oriented language I think you’ll find the lack of ‘objects’ to be disheartening.  Add to it that there is no auto complete for the Script Editor and I think it’s a deal killer for me.  Those two features make discovering events, properties, and methods so much easier without having to constantly check the documentation and I think it’s a huge adverting for Xojo.

The lack of strong datatypes, while not a deal killer, scares me a little.  I want to be warned early, often, and loudly when things go wrong and strong datatypes are something that I really find attractive in a programming language.  If there’s a data conversion going on it’s because I want it to happen (don’t get me going on Xojo variants – they’re evil – get over it).  The natural English scripting language also puts me off simply because it’s unnecessarily wordy.  Again, if you’ve never programmed before this might be an advantage.

The lack of native looking controls is also huge drawback for me.  Xojo apps will try their best to look native (though Linux apps require more of a nudge than Mac/Win apps) and while not perfect, out of the box, Xojo apps are generally native.

Conclusions

Is LiveCode worth a look?  Sure.  Like any development environment, if it speaks to you and you can get your projects done in it then it’s the right one for you.  For me, Xojo is a better language, with a better IDE, and has more features that I want.  Xojo is only lacking Android support and I’d probably look more at Xamarin than LiveCode for a variety of reasons.

If LiveCode works for you that’s great.  This review isn’t meant to be overly critical of the tool but as an existing Xojo developer I don’t see enough reasons to switch from Xojo development to LiveCode.  Feel free to leave comments below on anything you feel I missed or got wrong.

Xojo Cloud Database Support

Last week Xojo announced new features for Xojo Cloud.  They now support MySQL and PostgreSQL database servers in addition to SQLite that they have supported since day one.  One of the interesting features with the database support is that db admin tools that support SSL tunnels can connect to the database as if it was running locally.  In my testing it was surprisingly easy to setup and use.

The first thing to do is log into your Xojo Cloud account control panel.  Then simply enable either the MySQL or PostgreSQL database and enable the SSL Tunnel.  In each case you will receive a username and password that you’ll need to copy before moving on to the next step.

Screen Shot 2015-02-26 at 10.28.25 AM

Our MySQL admin tool of choice is NaviCat.  Setting it up was pretty easy to do.  Create a new connection and then navigate to the SSH tab.  Enter your server IP address, the username and password.

Screen Shot 2015-02-26 at 10.32.30 AM

Then navigate to the General tab and enter a Name for this connection (I used Xojo Cloud).  Because you’re using the SSL Tunnel you need to enter ‘localhost’ into the Host field.  Enter your Xojo supplied username and password and then test your connection.

Screen Shot 2015-02-26 at 10.38.00 AM

After that, everything acts just as if the server were local to you.  In this example I created a sample database named ‘bkeeney’ and a table called ’t_temp’.

Screen Shot 2015-02-26 at 10.34.09 AM

Your Xojo web application, then, will connect to it via the localhost parameter along with username and password suppled to you from Xojo.  Because it’s inside the firewall your web app needs to do nothing more.

Setting up a database server in Xojo Cloud really is that simple.  It just works.  From start to finish it only takes a few minutes to get up and running.  It’s a great addition to Xojo Cloud.

XojoTalk

One of the things that I love about the Xojo community is that it’s pretty friendly group.  You ask a question on the forums and you’ll usually get a decent answer or two.  This means that we’ve often ‘talked’ with Xojo experts but have never met them.  One of the things that stinks about the Xojo community is that we are a small enough group that it’s likely there are not a lot of Xojo developers near you.  That’s a shame because the Xojo developers I’ve met in person are as nice, if not nicer, than they were online.

If you can possibly attend the Xojo Developers Conference (this year it’s April 29 – May 1 in Austin, Texas) I highly recommend it.  Whether you are a newbie to Xojo or been around the block, as they say, a few times, I’ve always found it to be a good experience.  To be able to talk Xojo for 3 or 4 days is invaluable!  Nowhere on the planet will you find a higher concentration of Xojo developers per square foot.

Recently Paul Lefebvre, the Xojo Evangelist from Xojo, has been hosting a podcast called XojoTalk.  I love these podcasts because we get to hear from Xojo developers that we’ve ‘known’ for years through the forums and we get to learn a bit about them.  How they came to use Xojo and what they’re doing with Xojo.

Often the conversations veer off into some strange topic that you wouldn’t expect.  When I was a guest back in October the Royals were starting their playoff runs and while I’m not much a baseball fan it was a BIG deal for those of us in the Kansas City region (29 years since our last playoff appearance).  We also talked a bit about the, then, recently announced Windows 10 and what it meant for Xojo developers.  These organic conversations are entertaining and well worth a listen.  Paul does a great job so check it out!

You can subscribe to the podcast via your favorite RSS reader via http://feeds.feedburner.com/xojotalk or via iTunes at https://itunes.apple.com/us/podcast/xojotalk-podcast/id920411434

My entire team will be at XDC.  We are doing only two sessions this year.  Carol is doing a database design session and I’m doing a reporting tools session.  Hope to see you there!

Xojo Trainer Feb 2015 Update

We released an update to Xojo Trainer today.  We’ve added over 8 additional hours of Xojo Training video to our package.  This brings the total up to over 60 hours!  Here’s the complete list of new video topics:

iOS

  • iOS Walkthrough
  • 1.0 iOS App Object
  • 2.0 iOS App Icon and Launch Images
  • 3.0 iOSScreens and iOSViews
  • 4.0 iOSTextField and iOSTextArea
  • 5.0 iOSButton and iOSMessageDialog
  • 6.0 iOSCanvas
  • 7.0 iOSHTMLViewer
  • 8.0 iOSImageViewer
  • 9.0 iOS Primitive objects
  • 10.0 iOSLabel
  • 11.0 iOSSlider
  • 12.0 iOSSwitch
  • 13.0 Xojo.Core.Tiemr
  • 14.0 iOSSegmentedControl
  • 15.0 iOSTable
  • 16.0 Xojo.Net.TCPSocket

New Framework

  • 1.0 Xojo.Core.Date
  • 2.0 Xojo.Core.Dictionary

Web Edition

  • PictureShare project

These are the same videos that we’ve been streaming to thousands of Xojo developers for years at http://xojo.bkeeney.com/XojoTraining/.  Now you can view these videos and get the source code that comes with them offline at any time on your Mac or Windows computer.

We recently hit a milestone on our online Xojo Training – we’ve now streamed over 9,000 hours of video to users all over the world.  All of this via a Xojo web app!

For more information on Xojo Trainer, please visit http://www.bkeeney.com/allproducts/xojo-trainer/

Xojo 2015 Release 1

This week saw the release of Xojo 2015 Release 1.  This release has only a couple of new features (and one really big change) but many smaller changes and bug fixes.

The biggest new feature for Xojo is that you can now build 64 bit iOS applications.  This is a big deal because Apple is making 64 bit iOS apps mandatory for those apps submitted to the App Store.  As of February 1st submissions to the App Store must be universal 32 bit / 64 bit app bundles.

In December 2014 Xojo gave us a tentative roadmap and met it as 2015 R1 was in a usable beta on February 1st.  This is an accomplishment in and of itself since Xojo rarely, if ever, gives us their schedule.  Not only gave a schedule but met it!  I’d say lets give them some kudos for being a bit more open and accomplishing their task!

So far in testing it appears that 64 bit iOS applications are solid.  This also means that the 64 bit compiler is working and works in a 32 bit application and debugger.  According to their December 2014 blog post the next up for the 64 bit treatment is Linux web/console and this will be much anticipated by anyone that’s tried to install a Linux web app on a 64 bit Linux OS and struggled to find 32 bit compatibility libraries.

Besides 64 bit for iOS, there are a plethora of bug fixes to the IDE, the new framework, and the compiler.  To say that the IDE received some love would be an understatement.  These changes should make for a more stable development environment.  The number of bug fixes is too many to list here and I highly recommend reading the release notes.

The IDE Icon Editor received another makeover (how many is this in the past 15 years?) that allows it to handle 1024 by 1024 icons.  Some unused sizes were removed and the output format is now PNG rather than JPEG2000.  In my own testing it seemed that images moved forward from older projects didn’t look quite right so you should definitely make sure your icon images are updated before doing a release.

The Web framework received a few important updates.  WebLabels now work properly on dynamically created WebContainers.  WebCheckboxes respond properly on touch devices.  WebContainer mouse event handlers no longer interfere with scrolling.  WebListbox no longer offsets the selection if placed inside a WebContainer and accessed from a touch device.  Internet Explorer now supports gradient fills.

The new framework received new Parse functions for Integer, Double, Single and will act like the existing framework Val and CDbl functions.  What this means, in reality, is that Parse is more lenient and doesn’t throw exceptions when it can’t figure out the value of the passed in Text.  I think it’s obvious that Xojo is mindful of how we are using the new framework and reacting to our (valid) criticisms and wants and needs.

Windows and Linux users didn’t receive much love in this release, however.  The release notes only have a few for each and those seem pretty minor.  One bug fix that affects everyone, but appears to affect Windows more, was the Serial control.  It appears that it was possible to receive incorrect data.

I think many will be happy with this release.  64 bit iOS applications were a necessity and everything else was bug fixes and expansions of functionality.  I wish more releases were like this (i.e. a few new features and mostly bug fixes).

As with any new release you’ll need to test it against your own projects to find out if you have any issues.

What are your comments about Xojo 2015 Release 1?

Xojo Open Source Projects

In my last post I talked about the state of the 3rd party market for Xojo.  It was a somewhat depressing talk for those already selling and a cautionary tale for those contemplating entering the market.  All is not bad news, however.  In some ways, the amount of open source source code available for Xojo is at an all-time high.

For many Xojo developers the must-have libraries are the Windows Functionality Suite  and MacOSLib .  These two libraries are great places to start to enhance your Windows and Macintosh applications respectively.  There are both free and wrap system API calls into Xojo classes and methods.  I would start with these two classes.

The folks at IntelligentVisibility have done some interesting things.  Their CalendarTimeChooser project is 100% Xojo code calendar and time chooser that is pretty slick, in my opinion.  Besides that they have a DropBoxAPI project, a Telnet class for Xojo, a Logging class, an AutoCompleteTextField, and a Loading Wheel control.

Long time Xojo user Kem Tekinay has released Kaju.  Kaju is a set of classes that can perform self-updates for your Mac, Windows, and Linux apps.  This solves some real world problems we all face and while Monkeybread Software has the Updater Toolkit it uses different technique for each platform and (from experience) troubleshooting can be difficult in getting the Sparkle framework working on the Mac.

Another long time user, Scott Boss, of Nocturnal Coding Monkeys, has released the Xojo Colors Module that aims to simplify the use of colors in your Xojo project.  Another project is XoDrill which is Xojo class that uses the Mandril APIs from MailChimp allowing you to send mass mailing through the MailChimp service.

iOS has only been out for one release, but it has received a lot of love from the community.  Some criticize Xojo for not being complete and not providing some basic functionality.  I disagree because Xojo should not have to provide everything – just the basics for us to do everything else.  I think it’s working because the work coming out of the community has been extraordinary.  If your Xojo iOS app needs gestures then xojoGestures is a great place to start.

If you are working with iOS then I hope you are spending a lot of time in the Xojo iOS forum.  The users there are turning out iOS declares at a prodigious rate and there are way too many to list here.  The forum should be your first place to search for a solution.

Xojo for iOS has introduced the new framework which, in come cases, is considerably different than the existing one.  XojoiOSWrapper  tries to bring those legacy framework methods to the new framework and specifically for iOS.  If you’re working with iOS AND desktop apps and trying to use a set of shared business logic between them you’re finding it hard to accomplish.  GlueKit for Xojo is a set of classes and methods from long time Xojo developer Phillip Zedalis of 1701 Software, that allows you to interact with a single class that bridges the new and old frameworks.

Perhaps this trend is part of a larger trend with software that tends to make things open source.  I’m still not convinced that this is the best thing, long term, but it does provide some stability with developers entering and leaving the community and having source disappear forever.  Regardless of the long term implications it shows that the Xojo community is alive and thriving.

If I didn’t catch your Xojo open source project I apologize profusely!  Any oversights are purely my error.  Please leave a comment with the link to your repository and a brief description of what it does.  And for those of you wiling to share your work with the community a big hearty THANK YOU!

Shorts 1.1

picAppIcon256We released a new version of BKeeney Shorts today.  Version 1.1 is a recommended update for all registered users and is a free update.

Version 1.1 has a number of improvements:

• Text blocks now have an AutoHeightAdjust property that lets them auto wrap their text and change the text height accordingly

• New demo report that demonstrates the automatic height adjustment in a row (i.e. GroupItem) of data of varying text

• The desktop version now has an RTF Block and uses the Formatted Text Control to convert into Shorts reports and HTML

• The Demo project for Web and Desktop comes with viewers you can use in your own projects

• Multiple demo reports with the various ways to create a report via code

More information on pricing, features, documentation, demo project, and more available at http://www.bkeeney.com/allproducts/bkeeney-shorts/

The State of the Xojo 3rd Party Developer Market [u]

BKeeney Software offers a variety of Xojo developer tools for sale. BKeeney Shorts is a reporting tool unlike anything else in the Xojo kingdom and allows you complete control over your reports. That is its strength and also its weakness since you have to fully code your report. We also offer a Calendar class for use in desktop applications, a cross platform Spell Checker plugin, and ARGen that creates the classes that ActiveRecord uses to make database coding easier and quicker in Xojo.

Over the years we were approached by developers that were leaving the Xojo market and wanted a home for their product. When True North Software decided to exit the Xojo market we purchased the rights to Formatted Text Control, RB Code Reports and a number of other Xojo related tools. When Pandaware left we picked up Simple Help Editor and Styled HTML Field. Many people were asking for PDF classes and had fond memories of Fireye Software’s PDF classes so we tracked down Asher and acquired those too.

We purchased these products from their respective owners either because we already owned the products or had a use for them. In some cases we simply updated the source code and in some cases we started a complete rewrite to suit our needs. This means that in addition to the original thousands of man-hours the original developers used to create them we’ve invested significant time and effort ourselves to work on them.

BKeeney Software can’t exist on the sales of these developer products. Developer product sales are lucky if they top 20% of our annual income. Most years it’s less than that. Our second highest income earner is our Xojo Training material but, by far, our best income source is our consulting services. With multiple Xojo developers that makes sense. Not only can we throw all of our developers on a project we can (and usually do) all work on separate projects. When one of us is idle (which thankfully isn’t very often) we find time to work on our applications and developer products (and me on training material).

I was on the receiving end of a grievance on the forums this week where I was accused of not delivering updates that I promised on one of the products. If I did nothing but work on our products I’d be out of business in short order and that product would just go away and who knows if anyone would pick them up.

This got me thinking. Am I unique in this position? So I queried some other Xojo developers to find out what the state of the Xojo 3rd party market is like and if they would share their thoughts. I received more information back than I expected.

Almost all of the developers I contacted said that product sales were a minor portion of their income with most stating it was less than 20% of their income. Jérémie Leroy has a full-time job and the Xojo business is just a happy sideline. Sam Rowlands said there was no way the sales of his developer products comes close to paying for itself. And,one of the more well known figures in the Xojo community, Christian Schmitz said, “Even with the scale I have with MBS myself. Consulting keeps the company running.”

From these statements, it’s pretty obvious that the 3rd party market, while not exactly stagnant, isn’t thriving either. Everyone I talked to has other sources of income besides their developer tool/utility sales. Part of this is probably because the Xojo market is small. Another reason might be the hobbyists that Xojo attracts and they simply don’t have the means to purchase tools. Another possibility is that Xojo has ‘good enough’ tools built-in and newcomers don’t need the more advanced commercial, add-ons.

One of the interesting comments I received from several developers was that it was those that purchased the cheapest version of their products (some offer encrypted and non-encrypted versions) created the most work for them. I’ve seen this myself with our encrypted source code that it seems to generate more support tickets than the full-source versions. Based on this feedback I am seriously considering removing the encrypted versions from our store and simply selling the full-source versions. It’s interesting that our one product that doesn’t have encryption (Formatted Text Control) doesn’t generate that much support help despite it being one of the largest and most complicated products we sell.

All of the developers I contacted felt that the future of Xojo is bright and holds promise. iOS development in Xojo might become as big as desktop and web which means new customers for their products. The new framework causes concern for many in the Xojo community but the developers I talked to were ecstatic that Xojo was listening to our concerns and making incremental changes to the new framework based on that feedback.

The 3rd party Xojo development tool market is tough business to make a living at. The fact that half our products came from developers leaving the community says something. That some of the most well known and respected voices in the community can’t make a living selling Xojo developer tools and have other sources of income is also telling.

So what can Xojo do to help us out? Growing the user base is the biggest thing they can do and it seems that having the iOS version is a step in growing the platform. One area of concern, though, is that many Windows users are unhappy with Xojo right now. They feel, rightly or wrongly is besides the point, that the focus has been so Apple and iOS oriented the past couple of years that they feel unwelcome. Some focus on making the Windows experience better would be reassuring to them.

I also think that Xojo could do more to promote the 3rd party products. Perhaps the Xojo Developer Evangelist could pick a product to review each month. Xojo Developer Magazine does reviews like this but it doesn’t receive the eyeballs that the official Xojo site gets. Personally I’d offer a discount for the people that purchase via the review. The market isn’t THAT big and it would be a good way to show off some products and generate sales for developers that are starving for income. More income means more of time for product development and everyone wins when that happens.

I feel the future is good. More Xojo users means more product sales (hopefully). This, in turn, means we can spend more time on those products and pump out updates on a regular basis. Until then, us 3rd party Xojo developers will continue with our labors of love and put updates out when we can.

What do you think of the 3rd party market? What could Xojo do to improve it?

[Update:  ]

After looking at our 2014 numbers our total developer products and training sales was LESS THAN 10% of our total income.  In 2013 the amount was more but amounted to less than 5% of our annual income (consulting was VERY good that year).  In other words, if we relied on our developer products and training to make a living we would quickly go out of business.

Seriously, why do I even bother with developer sales?  Just using them and updating them for ourselves would be cheaper in the long run.

Client Red Flags

I’ve talked before about those little things that prospective clients (and sometimes actual clients) do that should give you cause for concern.  These are those things that should be red flags and make you reconsider taking them as a client, or not keeping them as a client.  We recently took on a new client that had already burned through another Xojo developer before coming to us.

I’ll start off by saying that we have an entire stable of clients that came to us after they had tried out another developer.  Roughly 75% of our long term clients have come to us this way.  For some, the developer left the industry and recommend us to their client but for some the Xojo consultants had failed to deliver a working application even after quite a bit of time and money.  The clients came to us and they’re happy that we have multiple developers and have a breadth of experience that is hard to find elsewhere.  We’re also not going away anytime soon.

This client should have raised enough red flags for us to avoid from the start.  But, honestly, that’s easy to say in retrospect.  Sometimes you just won’t know until you work with them for weeks and sometimes months.  Plus, it was a smallish project that was only a couple of weeks long.  What could go wrong, right?

The clients first developer underbid us by a grand total of 10 hours but had significantly lower billing rate.  A couple of months later the client parted ways due to lack of progress from the first developer and called us back.  Red flag number one, in my opinion.  Clients have every right to be price conscious but one warning sign is if they’re trying to get the project done ‘cheap’ and ‘quick’.  While possible they also need to be flexible and this client was anything but.

The second issue with the client is that they kept using phrases “we want it exactly like this,” with ‘this’ being a VB6 application that looked like they coded it in 1995 and an HTML website that harkened back to the 90’s as well.  Even if Xojo could create such an application (it can’t without significant work) I’m not sure I would simply because creating a 20 year old GUI isn’t something I strive for.  We were going to create modern GUI (nothing crazy – just want Xojo gives us) with a database backend so the application could scale.  But they demanded flat files and a UI that looked ‘exactly’ like their prototype (which was non-functional).  Their reasoning?  Because they understood it and ‘their generation’ understands that look.  Hm…okay.

I guess my biggest issue with this client is they chose Xojo – not us.  There was nothing in the project spec (a VB6 app, a simple HTML web site, and some phone meetings) that said it couldn’t be done in Xojo and when we heard ‘just like this’ we translated this to mean ‘as close to this in Xojo as possible’ and when we didn’t make it look like the 90’s website they were mad and cancelled the contract despite us redesigning the app twice in attempt to mollify them.

In retrospect, the client doesn’t really want a Xojo developer.  They want an HTML and php developer that will do exactly what they want.  No more.  No less.  The signs were there from the beginning – we just failed to see it.

In the long run it’s just another red flag example that I hope to learn from and I hope that you don’t have to go through either.