The relentless drive to control every part of the world from a browser-based widget is now turning on itself.
Not only are all of our desktop applications being replaced with HTML, but the act of creating a Web application itself has moved to the Web.
The new platform from Coghead lets anyone build Web applications by pointing and clicking at another Web application. The only time you need to edit ASCII is when you’re putting labels on columns and widgets.
This development shouldn’t be surprising. Many of the AJAX toolkit makers like JackBe and Backbase built their own development environments out of their own toolkit, a nice gesture of eating their own dog food. Coghead takes this trend to the logical end by encouraging anyone in any coffee shop with free Wi-Fi to just log right into a free account, click a few times to spin up a data structure, and roll out the application. Coghead’s cloud, built firmly on Amazon’s cloud foundation, does the rest. Your new application then appears on the Web as a cloud to your users, an effect that turns the word “cloudy” into a compliment.
It’s not surprising that the Coghead folks like to talk about how their customers are building cool applications without writing any lines of code. Programmers themselves invented this conceit when they started telling their managers that the new XML configuration files would let the managers control the software without doing any coding. Ha.
What this statement really means is that anyone can whip up a Web application without typing ASCII words in some C-like syntax that needs to be parsed by a compiler. You just drag and drop some form widgets onto pages and the data model morphs to support it. If you improve a customer contact entry form by inserting a new pull-down menu for favorite baksheesh, a nice column for baksheesh appears in the database table holding the information on all of the customers. It’s all automatic. It’s a lovely way to build up a few tables by just drafting the forms.
Coding no, programming yes
Creating a complete application, though, requires doing some of the abstract thinking that programmers will recognize as something that they do every day. Cleaning up the data model, dealing with incongruities, planning for future expansion, and good refactoring are all still necessary. You may not be typing ASCII code in a C-like syntax as you do it, but I think most programmers will think of it as programming in much the same way as kids see right through a parent’s attempt to relabel yard work as character building, nature reintegration, or Vitamin D therapy.
The real work for the programming part of your brain is creating the architecture for your data. Coghead wisely chose a fairly flexible data model where XQueries search through the data structures. A more traditional relational database usually requires plenty of JOINS and extra matching tables for many-to-many relationships. This makes collections of objects attached to other objects a bit simpler, and that helps with the overall appearance of the application.
One of the odd side effects of designing the data structure by building forms is that there’s a form for editing even relatively hidden tables that aren’t meant to be seen by the public. This means you often need to go through and build a simpler set of pages on top of the first, in effect creating a sort of wizard. The good news is that you don’t need to build an administrator’s console after you get things working for the end-user. The bad news is that the applications tend to offer endless forms. Getting things done at the beginning includes clicking on multiple forms and tables.
The real programming comes in when you start creating actions with the cute drag-and-drop flowchart builder. This mechanism is pretty slick and impressive, but I’m guessing it will drive old-school ASCII typers nuts. I found myself clicking and clicking and clicking to build up some basic if-then-else structures. A few lines of a C-like language could be spun up in a tenth the time because there’s no need to take your hands off the keyboard. Sigh. But I think this may sound curmudgeonly and old fashioned to visual thinkers.
It didn’t take me long to generate an inscrutable error message, the kind that leads to panic in mere mortals but inspires real programmers to roll up their sleeves. I was dragging some widgets around the flowchart tool for specifying what happens when you create a new database record and I thought I could just pop in an action to send some e-mail. One variable was wrong and a dialog box warned me, “BPEL process could not be generated — Action Projects/Send Email could not be converted to BPEL.”
Coghead turns the pretty flowcharts into BPEL structures. The drag-and-drop tool may look nice, but I think most serious Coghead programmers will need to learn BPEL syntax and then work backward to figure out why something isn’t working. Casual users can probably avoid much of this if they’re happy with the basic CRUD (create, update, and delete) operations.
A room with a view
The interesting part of Coghead emerges when you decide to start sharing your application with the world. It’s rare for one software company to handle this much of the stack. The developer tool companies usually are nowhere to be found when it comes time to move your code to a server. I once asked a friend who worked for Oracle for help just installing Oracle on my Linux box and he laughed. He couldn’t even do it himself and needed special help from other Oracle jockeys. Coghead has spent a fair amount of time thinking about this, and it offers versioning to let you roll out new features. It’s just another click on a Web form. You build, test, and deploy in the same world.
Coghead did realize that this total integration can scare some CIOs who equate it with total lock-in. The CIOs are half right, and Coghead is trying to dodge this limitation by offering an open API for doing your own queries to the database. The data is always yours. If you want to leave Coghead, though, you’re going to have to find another way to build the application that runs the data.
The real disruptive force behind Coghead lies in its payment model. Everything at Coghead is sold a la carte. Adding a user, storing some data, or putting a new record in a table all add small amounts to the bottom line. You don’t sign some hundred-thousand-dollar contract for some slick software salesdroid; you just commit to paying a monthly amount per user. When you activate your account, you pay for “members.” A pro account comes with five members for US$49 a month.
Coghead is trying to open up its platform to bigger applications by creating “limited users” with limited rights to work with only certain “access points” for the data. This approach makes it possible to offer bigger, more open applications to the world without paying $10 per month for a full-fledged member.
At first, I was thinking of these “members” as fellow programmers who are part of the development team because these members can do plenty. After a bit of thought, I realized that these members are really users, and there could be a wiki-like flavor to rolling out one of these applications. A small office with a custom application could give everyone the capability to edit any of the forms at any time.
Programmers will freak out about this feature in much the same way that encyclopedia authors shrieked at the invention of the Wikipedia. But I think it would be neat to let users add form entries. Well, most of the time. As long as there’s a programmer around to clean up the mess. There needs to be something for the programmers to do.