Paul Hammant's Blog: UI Development Has Never Been More Expensive
UI application development that presents and changes data in a data store, is at least an order more expensive than it was 20 years ago. It really should’t be given all that “progress” embodies.
I’m talking about time taken to achieve a change has gone up. If that has a dollar cost, I’m less interested it in because of the effects of inflation. It seems incredible that each successive UI technology launched didn’t beat the bang for the buck of it’s predecessor. Not quite criminal, as there’s no single malignant corporation behind this reality, but an industry failing for sure.
Contrast to TVs. “RCA first model debuted at $600 in 1939”:”. That is $10,000 in todays money. Today you can get a non-smart 24” TV for $130. That’s progress. Read more about TV prices over the years, if you’re super interested.
Then and Now
Back in the 90’s, with the likes of MS Access, FileMaker and Clipper, people could quickly put together database applications with forms for data entry and reporting. The people doing that might not have too much of a technical background, or perhaps were self-taught.
MS Access still exists, but these days we are persuaded to make applications using web technologies or fatter toolkits like Swing, WPF or Cocoa. The What MS Access can make is not appropriate for web deployment and mass concurrent usage. Firebase (amongst others) shows how technology can push in the direction of MS Access style simplicity, and handle some load when deployed. Most of the time though, custom app dev is going to rest on open-source web technologies, or fat-client bits and pieces and made in-house.
Data interaction
At it’s core MS Access has a “data binding” metaphor, which Microsoft has been a long term patron of. There’s simplicity in a form showing a row, the end-user transitioning to editing that, and using < and > controls to move to an adjacent rows in the underlying table or view. That suits CRUD applications of course, but much of what we need to construct at the high end today is not CRUD-like at all. MVC (the 1978 design pattern) comes to the rescue when you can’t be served by bata binding (and associated patterns), but means application construction is much more complex.
Markup
HTML came along in 1991, but many of us only had our first exposure in 1993. Simple site-centric things were all that was possible back then. If you were to view source there was a chance that you’d be able make simple changes and see the effect in a browser, without tuition of any kind. That low barrier to entry is gone today with a DOM that is constantly mutating, a pseudo-functional language (JavaScript) doing some of the mutation, and a CSS pipeline that makes the rendered view. Whereas non-technologists could pat themselves on the back in 1993 with their HTML coding ability, the field is so complicated presently that programming has effectively split in two to cope. The second half (relative new entrants) are UX designers with DOM skills. This new group does the fine grained UI work for browser apps, after developers make a functional starting point. There are new challenges for “search” presently, while we wait for Google and others to index non-static HTML.
Also, though HTML was all about markup in 1993, we’re seeing a second generation of technologies attempt to address the DOM directly without HTML as principal delivery technology. ExtJS, GWT and Cappuccino were the first generation. Meteor is leading the second generation. All of these miss the power of markup or DSLs for UI composition, in my opinion.
The browser wars play a big factor in the expense of modern application development. Microsoft versus Netscape (1995 - 2001) and Microsoft versus WebKit/Blink since, has meant for a very fragmented platform to target. This on it’s own might in itself count for a 2x on the cost of UI application development today. Microsoft are attempting to kill IE 6 through 9 as fast as possible, because they are fearful of the startups developing a “webkit only” strategy as a cheapener.
WYSIWYG design tools
MS-Access had that design mode, that was pretty close to the running visual for the same. Forms could be WYSIWYG designed, and would look the same when running. The downside is that there was no source as such, with loads of negative consequences. Lets say that the type of design tool that would load and save source, allowing you to alternately edit in a lowest-common-denominator text edit is called a “round-trip” editor. I think that is immensely valuable.
Dreamweaver for HTML-editing still exists, but nobody uses it, even though it was a perfectly round-trip capable as it would leave alone elements and expressions it did not understand. Nobody makes applications like that anymore: the need for rectangular decomposition moves development out of the sweet spot for Dreamweaver.
Life on Mac and iOS means that you get busy with Interface Builder, but it is far from perfect - severely diminished ability to edit the underlying files (no round-trip), and diminished merge capability for storyboard and XIB files. Java’s principal fat-UI technology is Swing. The eclipse foundation made another - SWT. Neither make for easy development experience, even if they do have source at their core (and are more mergeable than XML). They are not easy to program for because they do not have a natural markup for the UI side of their composition. JavaFX is a Swing derivative, and Sun’s attempt to make a more markup-like experience, but it missed the mark in my opinion.
What went wrong?
The industry, in the attempt to punch through glass ceilings (related blog articles 1 & 2) has abandoned people who are just beginning with application development. Instead, technology-makers have abandoned those that don’t want to get too technical. Whereas before you would reach a glass ceiling with a particular technology, and have to start over with some other technology (with costs), nowadays you’re not encouraged to “start simple” at all. There’s no pervasive technology that would allow for a simple beginning and also have the ability to do piecemeal changes to controls/forms/panels in order to add more sophisticated functionality without glass ceilings.
Back in the mid-90’s you would be using a technology made by a commercial vendor. If you encountered a glass ceiling, you could raise feature requests, but you would have to wait for the vendor to prioritize it and release something. That could take years (seriously). By 2000 the open-source space for enterprise application construction was vibrant. You had a new possibility: fill the shortfall (or fix a bug) yourself. Back then you’d donate a patch, and bug the developers on a mail-list, with the risk being they’d refuse to accept the enhancement. Nowadays you can fork the technology in question, giving rise to one more possibility - creating a community around your version of the same technology. As a result, glass ceilings are a little easier to punch through.
We should have been able to square the circle by 2014 though. Specifically UI technologies that are easy to get started with, that allow the swapping of simple markup for more sophisticated solutions in increments, without that being a rewrite.
What would that look like?
Please forgive the XML structure of the example that follows. The source below has a resemblance to HTML. It isn’t necessarily over HTTP. It could be thin or thick, though:
<form>
<title>Todos</title>
<todo bind-to="/data/todos*{filter}" order-by="order" save-on-field-exit previous-var="previous">
<table>
<row>
<col-heading reorder-var="order" reorder-default="ascending">Text</col-heading>
<col-heading reorder-var="order">Done</col-heading>
</row>
<row>
<text-filter var="filter" name="text"/>
<combo-filter var="filter" name="done" values="(Done)[true],(Not Done)[false]" all="Either"/>
</row>
<row foreach="todo">
<cell>
<output-click-edit var="todo.text"/>
</cell>
<cell>
<checkbox var="todo.done"/>
</cell>
</row>
<row new key="GUID">
<cell>
<text-field var="todo.text"/>
</cell>
<cell>
<checkbox var="todo.done">Done</checkbox>
</cell>
</row>
</table>
<revert-button show-if="previous != todo">Revert</revert-button>
</todo>
<form>
That form in use:
The form in a designer tool (hopefully round-trip capable):
Of course, it might be nicer if that were not XML
form: {
title: "Todos",
todo: {
bind-to: "/data/todos*{filter}",
order-by: "order",
save-on-field-exit,
previous-var: "previous",
table: {
row: {
col-heading: {
reorder-var: "order",
reorder-default: "ascending",
text: "Text",
},
col-heading: {
reorder-var: "order",
text: "Done"
}
},
row: {
text-filter: {
var: "filter",
name: "text"
},
combo-filter: {
var: "filter",
name: "done",
values: "(Done)[true],(Not Done)[false]",
all: "Either"
}
},
row: {
foreach: "todo",
cell: {
output-click-edit: {
var: "todo.text"
}
},
cell: {
checkbox: {
var: "todo.done"
}
}
},
row: {
new,
key: "GUID",
cell: {
text-field: {
var: "todo.text"
}
},
cell: {
checkbox: {
var: "todo.done",
text: "Done"
}
}
}
}
revert-button: {
show-if: "previous != todo",
text: "Revert"
}
}
}
You’ll have imagine a smooth round-trip interoperation between the design tool, and the same source being edited in Vim or Emacs.
While we wait for nirvana
Firstly AngularJS should be called out as the high-bar for markup today. At least in my opinion, though really it was a 2009 achievement and it’s authors had a commercial service a little in the style of Firebase. Obviously it’s for the browser, and it’s use in fat-clients is questionable as all web technologies are.
Secondly there is QML from the Qt folks which is a very compelling markup language for enterprise usage, and quite viable for cross-platform development. Note with http://qt.io they finally have a domain worth bragging about. When did that happen? No mention of QML on that site though :(