I know that Apple pushed WebObjects to the back burner when they acquired NeXT in the mid 90s but I'm not sure why it would be bad for them to buy 280 North today.
Unless there's a clear way for something to shift hardware, Apple isn't really interested in it. WebObjects has languished, despite being killer in more than one respect. An update (and de-java-ing) of WO tools with something like Atlas integrated would be absolutely killer, but unless it helps them shift more Macs in big numbers, I don't see it going anywhere.
My punt is that Apple is going to make a big enterprise play in the next 2-3 years. Time is ripe, and it can be done without a big investment in capital.
Wait until Steve Jobs publicly denounces enterprise IT as a business with no future. He'll be right, in more ways than one.
iWork, iCal server etc. Apple is in the middle of a large enterprise play. It's just not a big marketing push yet, they're likely waiting for the product to mature a bit.
I can't give this topic the justice it deserves in an HN comment, but yes I'll clarify.
In 10 years time, the "IT Department" virtually won't exist at most small-mid size businesses.
I think a lot of business software is going to be taken off-the-peg, or plug-boarded from open source software as interfaces approach ubiquity and organisations like government, banking and b2b start to expose consistent "APIs". It's already happening now.
We also have gen X and Y moving into senior management and the internet generation actually moving into work. Computer skills are getting to the point of being virtually innate.
Acquiring computer equipment will be analogous in business to buying a photocopier or some other office equipment.
Absolutely agree with you on all points. I've been saying this for a few years too, and you see it happening now with cloud computing replacing IT guys in startups.
I'm actually very happy this is occurring because more than 50% of the time, dealing with the IT guy is like dealing with a bad police officer. It seems like they're always on some kind of misplaced power trip...
Seriously? I hear this all the time; do you guys work in IT or in web development? The web people are way over on another page. ERP is primarily the reason IT exists and ERP packages take DECADES to change - witness the MASSIVE amount of COBOL still around (including here). ERP deployments are complex and almost always customized.
I suspect Gen X and Gen Y (which includes me) generally doesn't have a clue at what goes on in a "real" IT center - meaning one that is not (a) some awesome start-up that will be forgotten dust tomorrow or (b) a web oriented consumer-facing business. Nothing in IT is anything like "buying a photocopier" nor will it ever be. The company that takes that approach will be run into the ground by its competitor that innovates.
I'm an IT contractor (never done web for money). My opinion was formulated based on my experience managing an IT division over 5 years or so and also doing various PM and architecture roles.
You can more-or-less validate the first 50% of my claim by giving a bunch of computer literate people some brand new boxed PCs or Macs, and an internet connection and telling them to go for it and set up their environment. They'll be able to get things up and running, and if they have a little bit of nous they will usually come up with something workable.
Of course, it won't be engineered. I did some work for a fairly big manufacturer about 10 years ago that opened a small office on the east coast of Australia. The small office got absolutely no IT support as it was off the radar, and because of the corporate structure Finance left them alone too.
They managed to brew up the essentials of what they needed using Access for sales/marketing, MYOB for the books and corporate webmail and hotmail. When IT found out, they went spare and "fixed" everything. The office suffered in both performance and morale because instead of their terrible (but working) homebuilt CRM and accounting systems they had to use a set of ancient AS/400 apps that were about 1000ms away (no problem for interactivity because they were on 5250 screens, but very slow turnaround). The PCs were useless too, IT made them log in to Netware and do file/print over an 8kbps CIR Frame Relay connection.
Government (and to a lesser extent business) exposing and unifying APIs and SAAS probably means that in 2009 situations like the one I messily chronicled above will scale, because the IT development and infrastructure component just isn't required. Someone somewhere else who knows all about scaling, security, DRP and backup has done it for them and is happy to charge a per-user-per-month fee.
If this happened now, they might have used a 37Signals product and Salesforce for example (no idea about the ERP side).
My current contract is a guerilla finance project to build some analysis tools for SOX compliance that they haven't been able to get corporate IT to deliver on for 3 years. We built a small app in Python with a web front-end (Django). It was quick, it worked, and it's a manifestation of people realising that IT has become commoditised and that IT doesn't have to be hard. I guess IT wanted to do something like build some ABAP programs in SAP using consultants that charge £800 a day on a 2 year timeline.
There's a lot of law firms, design offices and small practices that just go out and buy some macs and never even call in IT help. It's going to happen and keep happening, and it's difficult to see how the shift away from corporate IT could happen if you're focussed on changing the VAT rates in FORTRAN, applying PTFs to the iSeries, or keeping the active directory backed up. Shifts aren't usually obvious when you're in the thick of it.
I don't think the quickest typists in the typing pool ever thought that the managing director would type his own memos 30 years ago, either.
Heh. Serious power, terrible polish. They blew off all the NeXT veterans when they destroyed it as an objective-c development platform, but didn't finish the job of porting it to Java for five years so you ended up working on this platform that feels like a developed-in-isolation mainframe monster. Dev tools looked nice but made you want to slit your wrists from random crashes and other strangeness. There were a couple of periods where they looked like they would kill it which was stressful for people with codebases on it. All efforts at documentation did a very poor job of selling its incredible patterns and features.
But everyone I know who stuck at it has done well - many ended up at Apple working on very cool projects. I'd love to read a history of whoever wrote it one day - it was so far ahead of its time - I've got a theory that they had some people on it who had done serious research and practical time on some sort of web-like thin-client platform that pre-dated the web. Culture in Apple is different now too.
Cool. I browsed some of the products. Is it possible to browse by sex? When I was looking at shoes, I saw stilettos, even though I'm not shopping for my weekly drag show in Las Vegas.
Fantastic. RAD tools for the web haven't ever been done properly.
This could be huge.
The funny thing is, it actually looks quicker and easier than IB - probably because Objective-J is interpreted and runs in the browser, and it has the controllers in Atlas.
Fascinating... though I now feel like an old assembly programmer saying things like "In my day, we wrote Javascript by hand, and it only consumed suchandsuch memory and was blazing fast... now you with your newfangled GUI builders..."
This really is amazing. But it makes me nervous. I'm open to the idea, but just as I prefer using a text editor to write my HTML code rather than Dreamweaver, I'm concerned that this can take me too far away from my web app code.
Like any other tool, in order to use it effectively you have to master the tool just like you'd master a language. Hopefully what's under the hood here and the code it generates makes it easy to do that.
In order to build views with Cappuccino today, I'm doing it by hand (i.e. subclassing for example a CPView and constructing child visuals) - this means instancing elements such as CPTextField, CPButton, etc. and adding it to a view.
But being able to do it visually ala Interface Builder with similar semantics around delegates, subclassing, IBAction and Outlet concepts will rock - speeding up development time tremendously.
Cappuccino doesn't use html as it's main language. HTML / CSS / Javascript are Cappuccino's assembly language. You write everything in their Obj-J language (which is a cross between Javascript & Obj-C. And apparently actually all legal javascript).
I don't know how y'all plan to make money, but don't get too caught up in dev tools! They're fun, and might be good marketing, but be sure they're actually saving time against making the thing that people with money actually want.
These guys are awesome and I feel kind of bad to say this, but it's the perferction of a failed idea. I've been trying these kinds of GUI builders for almost 20 years, starting with VB and PowerBuilder, and I always ended up not actually using them.
The usual criticism is that they generate awful code, but that's not necessarily the case. The problem is really that these tools ask you to keep clicking on lots of little sliders and lines and bars and shapes and then click over there in that text box to enter a name and then select this or that from a list or menu, wait until that three pixel graphic changes its shape into a handle so you can drag that line over here, etc, and there's no way to automate this.
It's a matter of taste whether you like to do it that way when you create _one_ form, but once you create an application or two or three you have to abstract from the repeating patterns and you can't do that with the GUI builder.
GUI builders make you stay on the same level of abstraction forever because they don't have the equivalent of meta programming or even just plain procedural programming.
The reason why code built with GUI builders is so awful is not so much that they necessarily generate bad code. It's that developers who can put up with repeating the same clicks and drags on the same level of abstraction for years and years are in the wrong profession and create bad code regardless of the tools.
Programming is all about abstracting and automating stuff. The pinnacle of GUI builder based abstraction is what Microsoft calls "user controls". All they abstract is a bunch of widgets statically glued together on a panel. Great, but that's like 5% of what you want to do.
I'm afraid GUI builders are hopeless for any serious programming.
I agree with a lot of what you say here, and have had much the same experience, but there is one powerful counter-example in Apple's "Interface Builder". I get the impression that most Cocoa developers use it for at least some part of their code.
You've got some good points, but Interface Builder (and I imagine Atlas) departs fundamentally from VB and PowerBuilder in that the code doesn't live directly behind the GUI elements. Instead, it's connected by a series of inlets and outlets that are designed to allow for reusability and model-view-controller disconnect.
You can also define UI things in code in Cappuccino (as well as Obj-C).
IB is optional with Obj-C, and I imagine Atlas will be optional with Cappuccino.
To be precise Interface Builder doesn't actually generate ANY code at all. You are manipulating in-memory objects and setting their properties. When you save your UI it's effectively just a serialized form of the objects you were playing with.
The key point that I was trying to make is that IB is fundamentally separate from the code that is running in the application. In traditional RAD tools like VB, Delphi and Powerbuilder the interface and application logic are one and the same, you literally have code behind each form and each UI element.
Apologies - I read "in that the code doesn't live directly behind the GUI elements" as an inference that it lived somewhere else. I just wanted to add a clarification in case others read it the same way.
IB is a standard run-of-the-mill GUI builder. I found nothing in it that current versions of Microsoft tools don't do, quite the contrary. But the important thing is that separating code from the UI a bit better than VB did in 1992 is not what I mean by abstraction.
There are a few fundamental requirements for a language to allow for powerful abstractions. I think self-referentiality and closure (in the maths sense not in the CS sense: http://en.wikipedia.org/wiki/Closure_(mathematics) ) are among those requirements.
GUI tools are ages behind what today's programming languages can do in terms of abstraction. So I don't see why it should be a good idea to limit the expressiveness of my toolset by inserting static blobs or nibs of visual somethings everywhere.
To make it perfectly clear: I want to be able to insert a function in place of any static structure, anywhere! I don't want barriers that make this process more difficult. And that's what GUI builders do.
You say I can define UI things in code as well. Great, I'll gladly take that offer, thank you very much ;-)
Stimulating points, but it's far from "failed" in commercial terms; and the best GUI designers often aren't coders, but designers. Different tasks, different values.
Challenge: how could one make a visual version of abstraction? Would you say that there is no abstraction in templates?
You're right about the designer/coder separation. I didn't think of that because I have never worked in an environment where designers created functional UIs.
Yes there is abstraction in templates. Templates typically let you indicate (visually or otherwise) what the static parts look like and where the dynamic parts go. That's it. We have done that forever. There's no progress. Templates don't describe interaction and that's what UIs are there for and it's the growing part of UI design.
Tool vendors have tried for many years to describe the interaction parts visually as well. But interaction is not inherently visual. A condition is not visual. A data transformation is not visual. Even the difference between two visual states is not visual itself.
It's a logical abstraction that manipulates visual objects. Mixing logic that manipulates visuals with the visuals themselves is not useful, and in terms of established software design principles it violates the separation of concerns.
Painting logic with a GUI builder is like entering a sine function by drawing squiggly lines on the screen.
Maybe we could create a better visual version of abstraction, but I don't feel it's the most promising direction to take in order to make abstraction more powerful.
Templates can be reused across projects, and there could be a hierarchy of inheritance (don't know if that's done though).
I agree that visual programming seems to be one of the great failed dreams - lots of academics and practitioners tried it, and it just doesn't seem to work. Although, the crop of XML-mappers (mapforce, biztalk mapper) do represent simple functions in a visual language, and seem to own that market. I agree it's not serious programming, but more "coding for non-coders" (and it's marketed as such). Yet, it has a place - this time, for business analysts. There are non-programmers everywhere who need to do some kind of coding - and creating a safe, useful tool for them is worthwhile. And maybe even for coders sometimes, if (and only if) the task really doesn't need serious programming. Examples: make; regular expressions; paths; printf/scanf; JSON; HTML (though these mini-languages aren't visual, they also aren't suitable for serious programming). I'd add SQL, bash, sed and awk, but they are powerful enough; just awkward.
I was intrigued by your suggestion that one can't abstract a visual language. While there are templates, maybe one can do better. The anchors and widgets changing the placement on resize are a kind of abstraction - but you're right, you can't make your own abstractions. No one's done it - it doesn't mean there isn't a way to do it. Maybe there is.
However, for interaction, I think you're pretty right. Although some standard styles of interaction, and standard ways of generalizing/abstracting them could be captured, you can't have create new styles or generalizations using this system. It isn't powerful enough.
> Maybe we could create a better visual version of abstraction, but I don't feel it's the most promising direction to take in order to make abstraction more powerful.
The thing about visual programming is that it helps people. I agree it's unlikely to make abstraction more powerful (though with pure research you don't know what you'll find). I think it would be really cool to create visual abstraction, that is usable and intuitive, when it seemed impossible.
PS: just a thought: if an "interaction" a kind of mapping where by if you do X, then Y happens, could that not be represented in the same visual way that XML mappers use (above)? Functional abstraction could also be represented as a visual mapping - but it certainly is not a natural or intuitive form for it.
I agree with you that visual tools are probably not finished as a means for non-programmers to automate things. You point about regular expressions and SQL is very good. Some business people have been doing amazing stuff with Excel or even Access and I know people who use visual regex builders to reorganise the tags and titles of their mp3 files.
What's important, though, is that these people don't build UIs. First and foremost they manipulate or analyse data. The data is at the center. The important thing is a simple data model that follows the closure principle (filter tables and you get tables, filter text and you get text). The UI is there to support this simple data model and it has to be similarly reductionist I think. Placing arbitrary UI widgets on forms is not the way to do this.
Yes, more fundamental research please :-) Maybe machine learning could be used to let users correct the system's guesses rather than initiating some action. That would go further in the direction that graphical UIs have begun, which is to let users select from what is offered to them and react instead of making them give commands to the system.
Or maybe some of the thinking that has gone into computer games would be useful, I don't know.
"You can't build a UI builder with a UI builder". :-)
I like your point about users "reacting" to an limited range of choices, explicitly stated (and surely using domain specific terminology). It's a grammar you don't have to internalize, with libraries you don't have to know about, or know the search terms to find term. It's very "discoverable", and the limited and clear range of choices minimizes the information content (increasing the probability of obtaining the desired outcome). I'm sure it would also prune the tree by omitting choice combinations that don't make sense.
I think people don't like the system guessing for you, like Office's Clippy. Maybe it's OK if the user asks for the guess - like getting a list of search results; or vim/bash completion; or suggestions (google, Stackoverflow)
visual programming seems to be one of the great failed dreams - lots of academics and practitioners tried it, and it just doesn't seem to work
LabView is pretty powerful. Commercial, expensive, often annoying -- but pretty powerful. Integrates very cleanly w/ Visual Studio for text-based programming, too.
Adobe is working on a promising product called Catalyst that aims to allow designers working on Illustrator/Photoshop templates to convert them into Adobe Flex UI screens (mxml). It is promising because from what I've seen so far the mxml isn't very developer friendly.
The aim, of course, is for the designer to generate the exact look and feel for the wireframes and render them (using Catalyst) to MXML for the Adobe Flash/Flex developer to code in the behavior/functionality. Catalyst will require Flex Builder 4 (which will not be out until 2nd half of 2009).
Adobe (and the assimilated Macromedia) are the state of the art at UI for designers (Photoshop; Flash authoring tools). While they can include interactivity for many standard widgets (much as Word includes code for many standard typographical symbols), they can't customize the interactivity within the tool. It still needs developers, who must work with the generated code...
OTOH, there's an argument that standard interaction is a good thing, so maybe a lack of customization/abstraction isn't so bad?
I've created a 'Discuss YC: Adobe Flex' thread. Perhaps we can use that as an anchoring point for discussing Flex on News.YC (I read the guidelines - it seems to be not explicitly dis-allowed)
I think you need to take a closer look at the Mac third party application Community. We have been using a GUI builder called interface builder since NextStep existed, and it is far from failed for us. When it is done right it works well.
I'm not sure how Atlas works, but on the mac code is not Generated in the way you are thinking. You should really check it out.
To nip this one in the bud: Atlas doesn't generate code. It serializes the objects that represent the "views" and other objects. This has a number of advantages over the code generation method.
Also, I think Atlas allows for the sort of abstractions you're looking for. It comes with a bunch of built in widgets which are great, certainly for prototypes and simple UIs, but even fairly advanced ones too. But if they're not good enough, or you have some custom widget/layout you can easily add it to Atlas as a plugin and treat it as if it were a built in component.
But I'm certainly interested in hearing more about the problems people have with these sort of tools.
I think this has some potential to allow more developers to publish a web app with at least a decent looking ui. There are a lot of good backend developers who happen to be bad at ui, this might allow more potential customers to view the product instead of being horrified as soon as they saw the ui.
Sorry about that. We're still in a hotel in Miami with shitty Internet. Will be back in California tonight and everything should be smooth sailing after that.
76 comments
[ 3.4 ms ] story [ 205 ms ] threadI can't believe how awesome these guys are, I hope Apple acquires them and starts using their technology for MobileMe + iWork.
I know that Apple pushed WebObjects to the back burner when they acquired NeXT in the mid 90s but I'm not sure why it would be bad for them to buy 280 North today.
Wait until Steve Jobs publicly denounces enterprise IT as a business with no future. He'll be right, in more ways than one.
I'm no groupie but I'd hate to see him go.
Can you clarify? Because that seems very misinformed. Unless you mean on-premise deployments, which has been on the way out for years.
With SaaS + cloud computing, Enterprise IT is just starting to get interesting again.
In 10 years time, the "IT Department" virtually won't exist at most small-mid size businesses.
I think a lot of business software is going to be taken off-the-peg, or plug-boarded from open source software as interfaces approach ubiquity and organisations like government, banking and b2b start to expose consistent "APIs". It's already happening now.
We also have gen X and Y moving into senior management and the internet generation actually moving into work. Computer skills are getting to the point of being virtually innate.
Acquiring computer equipment will be analogous in business to buying a photocopier or some other office equipment.
</crystalball>
I'm actually very happy this is occurring because more than 50% of the time, dealing with the IT guy is like dealing with a bad police officer. It seems like they're always on some kind of misplaced power trip...
I suspect Gen X and Gen Y (which includes me) generally doesn't have a clue at what goes on in a "real" IT center - meaning one that is not (a) some awesome start-up that will be forgotten dust tomorrow or (b) a web oriented consumer-facing business. Nothing in IT is anything like "buying a photocopier" nor will it ever be. The company that takes that approach will be run into the ground by its competitor that innovates.
I'm an IT contractor (never done web for money). My opinion was formulated based on my experience managing an IT division over 5 years or so and also doing various PM and architecture roles.
You can more-or-less validate the first 50% of my claim by giving a bunch of computer literate people some brand new boxed PCs or Macs, and an internet connection and telling them to go for it and set up their environment. They'll be able to get things up and running, and if they have a little bit of nous they will usually come up with something workable.
Of course, it won't be engineered. I did some work for a fairly big manufacturer about 10 years ago that opened a small office on the east coast of Australia. The small office got absolutely no IT support as it was off the radar, and because of the corporate structure Finance left them alone too.
They managed to brew up the essentials of what they needed using Access for sales/marketing, MYOB for the books and corporate webmail and hotmail. When IT found out, they went spare and "fixed" everything. The office suffered in both performance and morale because instead of their terrible (but working) homebuilt CRM and accounting systems they had to use a set of ancient AS/400 apps that were about 1000ms away (no problem for interactivity because they were on 5250 screens, but very slow turnaround). The PCs were useless too, IT made them log in to Netware and do file/print over an 8kbps CIR Frame Relay connection.
Government (and to a lesser extent business) exposing and unifying APIs and SAAS probably means that in 2009 situations like the one I messily chronicled above will scale, because the IT development and infrastructure component just isn't required. Someone somewhere else who knows all about scaling, security, DRP and backup has done it for them and is happy to charge a per-user-per-month fee.
If this happened now, they might have used a 37Signals product and Salesforce for example (no idea about the ERP side).
My current contract is a guerilla finance project to build some analysis tools for SOX compliance that they haven't been able to get corporate IT to deliver on for 3 years. We built a small app in Python with a web front-end (Django). It was quick, it worked, and it's a manifestation of people realising that IT has become commoditised and that IT doesn't have to be hard. I guess IT wanted to do something like build some ABAP programs in SAP using consultants that charge £800 a day on a 2 year timeline.
There's a lot of law firms, design offices and small practices that just go out and buy some macs and never even call in IT help. It's going to happen and keep happening, and it's difficult to see how the shift away from corporate IT could happen if you're focussed on changing the VAT rates in FORTRAN, applying PTFs to the iSeries, or keeping the active directory backed up. Shifts aren't usually obvious when you're in the thick of it.
I don't think the quickest typists in the typing pool ever thought that the managing director would type his own memos 30 years ago, either.
Heh. Serious power, terrible polish. They blew off all the NeXT veterans when they destroyed it as an objective-c development platform, but didn't finish the job of porting it to Java for five years so you ended up working on this platform that feels like a developed-in-isolation mainframe monster. Dev tools looked nice but made you want to slit your wrists from random crashes and other strangeness. There were a couple of periods where they looked like they would kill it which was stressful for people with codebases on it. All efforts at documentation did a very poor job of selling its incredible patterns and features.
But everyone I know who stuck at it has done well - many ended up at Apple working on very cool projects. I'd love to read a history of whoever wrote it one day - it was so far ahead of its time - I've got a theory that they had some people on it who had done serious research and practical time on some sort of web-like thin-client platform that pre-dated the web. Culture in Apple is different now too.
Seems like there is a good text editor being used in Atlas, hopefully this will make its way into Cappuccino soon!!
http://stylous.com/
Use it to build management guis, customized to the user. "Ohh, you want sales per hour, but don't care about inventory?" Here you are.
This could be huge.
The funny thing is, it actually looks quicker and easier than IB - probably because Objective-J is interpreted and runs in the browser, and it has the controllers in Atlas.
Postscript imaging model == HTML5 Canvas, Postscript == Javascript.
Hmm...
What percentage of the computer population knows what X Windows is, much less has any idea how to use it?
Like any other tool, in order to use it effectively you have to master the tool just like you'd master a language. Hopefully what's under the hood here and the code it generates makes it easy to do that.
But being able to do it visually ala Interface Builder with similar semantics around delegates, subclassing, IBAction and Outlet concepts will rock - speeding up development time tremendously.
the problem continues to be generated code...its bloated, has performance issues, and can't be maintained as easily as it can be created
I don't know how y'all plan to make money, but don't get too caught up in dev tools! They're fun, and might be good marketing, but be sure they're actually saving time against making the thing that people with money actually want.
The usual criticism is that they generate awful code, but that's not necessarily the case. The problem is really that these tools ask you to keep clicking on lots of little sliders and lines and bars and shapes and then click over there in that text box to enter a name and then select this or that from a list or menu, wait until that three pixel graphic changes its shape into a handle so you can drag that line over here, etc, and there's no way to automate this.
It's a matter of taste whether you like to do it that way when you create _one_ form, but once you create an application or two or three you have to abstract from the repeating patterns and you can't do that with the GUI builder.
GUI builders make you stay on the same level of abstraction forever because they don't have the equivalent of meta programming or even just plain procedural programming.
The reason why code built with GUI builders is so awful is not so much that they necessarily generate bad code. It's that developers who can put up with repeating the same clicks and drags on the same level of abstraction for years and years are in the wrong profession and create bad code regardless of the tools.
Programming is all about abstracting and automating stuff. The pinnacle of GUI builder based abstraction is what Microsoft calls "user controls". All they abstract is a bunch of widgets statically glued together on a panel. Great, but that's like 5% of what you want to do.
I'm afraid GUI builders are hopeless for any serious programming.
You can also define UI things in code in Cappuccino (as well as Obj-C).
IB is optional with Obj-C, and I imagine Atlas will be optional with Cappuccino.
I didn't say anything about IB generating code.
There are a few fundamental requirements for a language to allow for powerful abstractions. I think self-referentiality and closure (in the maths sense not in the CS sense: http://en.wikipedia.org/wiki/Closure_(mathematics) ) are among those requirements.
GUI tools are ages behind what today's programming languages can do in terms of abstraction. So I don't see why it should be a good idea to limit the expressiveness of my toolset by inserting static blobs or nibs of visual somethings everywhere.
To make it perfectly clear: I want to be able to insert a function in place of any static structure, anywhere! I don't want barriers that make this process more difficult. And that's what GUI builders do.
You say I can define UI things in code as well. Great, I'll gladly take that offer, thank you very much ;-)
Challenge: how could one make a visual version of abstraction? Would you say that there is no abstraction in templates?
Yes there is abstraction in templates. Templates typically let you indicate (visually or otherwise) what the static parts look like and where the dynamic parts go. That's it. We have done that forever. There's no progress. Templates don't describe interaction and that's what UIs are there for and it's the growing part of UI design.
Tool vendors have tried for many years to describe the interaction parts visually as well. But interaction is not inherently visual. A condition is not visual. A data transformation is not visual. Even the difference between two visual states is not visual itself.
It's a logical abstraction that manipulates visual objects. Mixing logic that manipulates visuals with the visuals themselves is not useful, and in terms of established software design principles it violates the separation of concerns.
Painting logic with a GUI builder is like entering a sine function by drawing squiggly lines on the screen.
Maybe we could create a better visual version of abstraction, but I don't feel it's the most promising direction to take in order to make abstraction more powerful.
I agree that visual programming seems to be one of the great failed dreams - lots of academics and practitioners tried it, and it just doesn't seem to work. Although, the crop of XML-mappers (mapforce, biztalk mapper) do represent simple functions in a visual language, and seem to own that market. I agree it's not serious programming, but more "coding for non-coders" (and it's marketed as such). Yet, it has a place - this time, for business analysts. There are non-programmers everywhere who need to do some kind of coding - and creating a safe, useful tool for them is worthwhile. And maybe even for coders sometimes, if (and only if) the task really doesn't need serious programming. Examples: make; regular expressions; paths; printf/scanf; JSON; HTML (though these mini-languages aren't visual, they also aren't suitable for serious programming). I'd add SQL, bash, sed and awk, but they are powerful enough; just awkward.
I was intrigued by your suggestion that one can't abstract a visual language. While there are templates, maybe one can do better. The anchors and widgets changing the placement on resize are a kind of abstraction - but you're right, you can't make your own abstractions. No one's done it - it doesn't mean there isn't a way to do it. Maybe there is.
However, for interaction, I think you're pretty right. Although some standard styles of interaction, and standard ways of generalizing/abstracting them could be captured, you can't have create new styles or generalizations using this system. It isn't powerful enough.
> Maybe we could create a better visual version of abstraction, but I don't feel it's the most promising direction to take in order to make abstraction more powerful.
The thing about visual programming is that it helps people. I agree it's unlikely to make abstraction more powerful (though with pure research you don't know what you'll find). I think it would be really cool to create visual abstraction, that is usable and intuitive, when it seemed impossible.
PS: just a thought: if an "interaction" a kind of mapping where by if you do X, then Y happens, could that not be represented in the same visual way that XML mappers use (above)? Functional abstraction could also be represented as a visual mapping - but it certainly is not a natural or intuitive form for it.
What's important, though, is that these people don't build UIs. First and foremost they manipulate or analyse data. The data is at the center. The important thing is a simple data model that follows the closure principle (filter tables and you get tables, filter text and you get text). The UI is there to support this simple data model and it has to be similarly reductionist I think. Placing arbitrary UI widgets on forms is not the way to do this.
Yes, more fundamental research please :-) Maybe machine learning could be used to let users correct the system's guesses rather than initiating some action. That would go further in the direction that graphical UIs have begun, which is to let users select from what is offered to them and react instead of making them give commands to the system.
Or maybe some of the thinking that has gone into computer games would be useful, I don't know.
I like your point about users "reacting" to an limited range of choices, explicitly stated (and surely using domain specific terminology). It's a grammar you don't have to internalize, with libraries you don't have to know about, or know the search terms to find term. It's very "discoverable", and the limited and clear range of choices minimizes the information content (increasing the probability of obtaining the desired outcome). I'm sure it would also prune the tree by omitting choice combinations that don't make sense.
I think people don't like the system guessing for you, like Office's Clippy. Maybe it's OK if the user asks for the guess - like getting a list of search results; or vim/bash completion; or suggestions (google, Stackoverflow)
LabView is pretty powerful. Commercial, expensive, often annoying -- but pretty powerful. Integrates very cleanly w/ Visual Studio for text-based programming, too.
The aim, of course, is for the designer to generate the exact look and feel for the wireframes and render them (using Catalyst) to MXML for the Adobe Flash/Flex developer to code in the behavior/functionality. Catalyst will require Flex Builder 4 (which will not be out until 2nd half of 2009).
http://labs.adobe.com/technologies/flashcatalyst/
FXG (the interchange format spec):
http://opensource.adobe.com/wiki/display/flexsdk/FXG+1.0+Spe...
As an aside, I work on a large project (at least 10 UI developers) that uses Flex. We don't even use the GUI builder.
OTOH, there's an argument that standard interaction is a good thing, so maybe a lack of customization/abstraction isn't so bad?
(That goes for any other Flex developers here as well. Seems that the intersection between HN readers and Flex developers is pretty small!)
http://news.ycombinator.com/item?id=495872
I'm not sure how Atlas works, but on the mac code is not Generated in the way you are thinking. You should really check it out.
Also, I think Atlas allows for the sort of abstractions you're looking for. It comes with a bunch of built in widgets which are great, certainly for prototypes and simple UIs, but even fairly advanced ones too. But if they're not good enough, or you have some custom widget/layout you can easily add it to Atlas as a plugin and treat it as if it were a built in component.
But I'm certainly interested in hearing more about the problems people have with these sort of tools.
People in this culture don't tend to build the kind of endless, mindless forms you're talking about. They build real apps.
And they don't generate code--they generate linked objects (freeze-dried in .nib/.xib and now .cib? files) that are unfrozen at runtime.
If you had to generate a whole bunch of mindless forms, you're right--metaprogramming solutions would be a big win.
Is it fast/responsive enough to not be annoying? No demo yet.
And I wish they had a one-line pitch.
Atlas is going to save me a lot of time.
Sure you can still edit the plist by hand or programatically but I don’t find it more efficient neither easier.