Still on a fence about GUI?

I wonder how many people and companies have given up on GUI, or maybe they’re permanently on the fence and looking for some way to jump off without getting hurt. This is just a frank discussion that might help some people in this situation. If you already have a GUI or you’re comfortable with your current solution, then I invite you to skip this blog entry and read another. But if you’re still not sure what you need to do or if your company is still in limbo, read on…

I confess I didn’t think this blog through very far. I have specific thoughts that I want to get out, and while this is poorly structured I hope this catharsis will help in its overall content.

When I create a GUI for an existing application, I dance with various languages, frameworks, and arguably helpful libraries. I try to minimize the number of tools involved but I also acknowledge that most tools aren’t suited for all purposes, so some balance needs to be struck between too few and too many tools in the kit. There are hundreds, no kidding, of libraries and frameworks for developers to choose from and a never ending stream of acronyms and buzzwords. Each addresses specific requirements of development, and attempts to solve some problem perceived by the tool developer. But at this point in the state of the art of web development, it seems like everyone has a solution for something and it’s impossible to tell who has the best solution for specific issues, or who has the best overall collection of solutions to categories of problems. How many developers are bewildered by the variety?

For this discussion I’ll completely ignore thick-client development – I don’t know a single company that’s working on a thick-click front-end for their app, whether with Windows Forms, Java, Flex AIR, or Linux Desktop. If you want to talk about thick client we can do that in email or the forum, or I’ll consider another blog just on thick-clients. My focus here is on the Browser User Interface (BUI vs the Character UI or CUI) and what’s generally known as a Rich Internet Application, or RIA.

What are some of the general challenges of BUI / RIA development?

• Browser differences complicate scripting, positioning of controls, handling of control events.
• Performance concerns affect decisions about how we move data from client to server.
• Many software providers are concerned about security, deployment, and performance of end-user workstations that we can’t control. This affects decisions about development and deployment tools.
• Technology is changing too rapidly and it seems to easy to make the wrong long-term decisions about anything.

In more detail, specific challenges or at least questions for BUI development include the following (not all isolated but taken in combination with one another):

• These days it’s not "if" you will use Ajax, but how.
• JSON or XML?
• Hardcode XmlHttpRequest, or use one of over a hundred libraries?
• How’s your knowledge of CSS? These days it’s absolutely required. CSS2? CSS3?
• How much do you know about "state" management and distributing data amongst client, middle-tier, and DBMS?
• Are you prepared to mix technologies? What about partial postbacks in most places for Ajax, but direct web services in other places for better performance? Or what about client-side events vs events handled on the server?
• How heavy do you code into JavaScript? Or do you think you can avoid it if you pile on enough tools?
• Do you use a helper library like jQuery or Prototype? Combine something like Moo and jQuery or ExtJS with Prototype? Again, hundreds of choices but really just a few good options. Didn’t know any of these existed? You should.
• Are you prepared for chronic browser compatibility issues? Do you mandate that your users can only make use of approved browsers?

I don’t care if you’re using Ruby on Rails, LAMP, or ASP.NET, you will need to answer those questions and perhaps build the skills required to address the issues. With the exeception of Rails, I’ve discussed those framework/stacks, as well as tools like Flex and Silverlight. Your choice of a stack is a major one but not the only one. Problems don’t stop when you’ve decided to adopt some popular stack, you’ve only narrowed down which primary toolkit you’re going to use to solve issues that are common to all.

And then there are choices like: Do you figure all of this out on your own, or do you pay an employee or contractor to do it for you? If you pay someone else, will your ROI from sales adequately cover the development expense? Can you continue to sell enough to cover ongoing maintenance expenses? If you do it on your own, is your time better spent learning the nuances of state management, or should you be writing application logic or out selling the software?

Many developers who have their own application have gone through one or more role transitions in their career: You started knowing a lot about a vertical industry. You found the MV DBMS platform where you can write code, sell your own software, and run your own business. Now the world has changed and the demands for doing it all yourself are often too great. To survive, the world is asking you to spend your time reading technical books and writing code that’s so far removed from Pick BASIC that it seems like it’s a foreign world. So do you once again shift from the role of developer, maybe to the role of mentor where you guide continued development and work more with prospects and customers? Do you retire because you can’t compete anymore? Do you hang up your own software and go work for someone else because you don’t want to deal with the techobabble?

Everyone has a different situation and there are no easy answers. Writing a new front-end for existing software is not trivial. It is extremely time consuming and can be expensive if you use tools that intend to save time, or if you commission people to do development with the intent of getting to market faster. But if you don’t put a GUI on your software, you know what you’re facing. You have a hard time selling to new sites. You worry about the survival of your business and obligations to your family. You wonder if you will be able to retire comfortably or if you’ll need to get a new job when you’re 65.

If you’re an employee at a company and you aren’t familiar with GUI then you face similar challenges. Will the company trade you in for someone with more modern skills? What if the company is bought and all you know is BASIC? What if the company starts to look at people who keep them on CUI as more of a liability than an asset?

For end-user companies or MV VARs that have their own staff of BASIC developers there are similar concerns. Can we sell the company or even get new customers if someone comes in and sees we’re running green screen applications? To create a GUI, can we make use of the current talent, people who have deep understanding of the business but no modern technical skills? How much does it cost to train technically savvy people for our line of business. If we hire people to do PHP (for example), how long are we stuck with that decision if we decide to go with Rails or something else?

You could opt to purchase software that claims to manage all of the issues for you, and I recommend you do look into products like DesignBais and Viságe just to see if they can aleviate some of your pain. But in my experience for some people these products can simply provide a trade off where some problems are solved in exchange for others. You don’t need to deal with Ajax but the vendor has ongoing issues with their choice of communications. You don’t need to deal with CSS or DHTML but the one and only provide you can get your solutions from now can’t provide the UI features you want until the next great release. I’m a big fan of making use of helpful tools but you must be prepared to shift your thinking away from what you think a tool should do, toward the mindset of what the provider thinks you need to do. If you accept whatever the provider offers then you’ll probably do OK. If you crave fine tuning and making use of the features you see on the internet then these tools are not for you. In return for their convenience and providing solutions (perhaps not exactly what you want but good "one size fits most" solutions nonetheless) providers of these tools ask you to pay a licensing fee. That’s only fair. They save you some grief and do a lot of the homework for you, and you get to produce a new GUI for sale to new audiences. If you want to avoid some of the licensing fees, whether for GUI tools or communications, or even the DBMS, then you’ll need to provide some components of your own. It’s the old "make or buy" decision.

For those still on the proverbial fence, I didn’t think I was going to offer any suggestions here but I confess I have a number of them in mind.

First, don’t worry about the major decisions. Surprisingly you’ll do just as well whether you make use of Ruby, LAMP, .NET, Flex, or some other. Just pick one and then research the hell out of it at the exclusion of all others. Do NOT get caught in this syndrome: As soon as you say LAMP someone else says "why not Rails?" … and you start to reconsider. The cycle of doubt will repeat itself endlessly. Pick a direction and go.

Second, when you’re in the midst of research or coding, it costs more to flounder for days or weeks than it does to ask for help and get solutions in minutes or hours. If you’re reading this and you haven’t made any progress yet, then just think how much it has cost you in terms of lost revenue to not ask for help. It’s either costing you money because no one is paying you to hunt endlessly for an answer to that little question, or it’s costing you in the long-term because you don’t have anything to sell. It’s time to consider the alternative with any or all of the following: Pay for mentoring. Pay for books. Pay for training. Pay for development assistance. Pay for tools. This is an investment. It shouldn’t be an expense. If you can’t pay up-front, partner with people for something now and a percentage of your earnings from sales later. In this economy that approach may be beneficial for everyone.

Third, I can’t be much more direct : My skills and those of our Nebula R&D colleagues are centered around providing modern interfaces for software. This is what we do! And this is what you do not do! There has to be some synergy here. If you’re not sure about the major decisions, we can help. For example, did you know that you can use ASP.NET with Linux/Apache, and it’s completely free? Know your options but don’t let lack of knowledge keep you in a perpetual cycle of indecision. Get help now, get your questions answered, get someone to help move the project forward. If you’re floundering with your own development, we can help. Concerned about costs? Let’s at least talk about it.

Whether you have employees work on a GUI for you, you do it on your own, you contract with Nebula, or with someone else – just remember that the first and worst enemy you face is the one that stops you from making the first tactical decision. When the discussion changes from "which direction should we choose" to "how do we improve performance on that screen refresh", you’ve completely changed the nature of your set of problems – a change for the better in my opinion. The problem you face should not be "how do we get to GUI" but how do we sell our GUI-enabled software in an increasingly competitive market. You can’t make decisions about how to make the play if  you’re not on the field. For now, I’m just trying to help companies get into the game. When you’re in the game and ready to call plays, I’ll be happy to elevate the discussion to that next level.