In a previous post on Web Design IDEs, mention was made of the just released EXTjs Designer which allows users to design an RIA JavaScript based interface using the EXTjs Framework. A review was promised – and so:
For $219 one can now buy the Designer and develop EXTjs interfaces more rapidly than ever. I currently use the powerful Notepad++ and with the Firefox browser launched by the Run command to develop EXTjs applications quickly. Prototyping a design with EXTjs Designer is faster and easier with the drag and drop operations and the Preview capabilities. In short order, developers can show the look and feel of an evolving design quickly to their clients and get rapid approval of the overall design. Then press the Export Project button and get the operational EXTjs code. Add the details and and formatting and one can deliver a EXTjs app faster. This is the good news.
But the bad news is that compared to IDEs like Net Beans for Java or QT for cross platform C/C++ development, EXTjs Designer is missing 5 critical features:
1)The development of Designs is one way – from screen layout to EXTjs code. But this is one way; developers cannot change the EXTjs code and expect to see the appropriate changes in the design.
2)There are no wizards for filling in widgets properties – this is most critical with database connections which is the strength of EXTjs with its great Charting, Grid, Form and Tree widgets among others which can be driven on live database data. But also FTP, RSS, XML Web Services are bereft of any Wizard help. One of the strengths of Microsoft Visual Basic from the get go was the many 3rd party widgets or extensions that took VB to a new level. Ditto for the iPhone’s 3rd party Apps. I am not sure EXTjs Designer even contemplates this type of capability. See here for a good example of a Properties Wizard in action.
3)The properties in the Component Configuration are confusing – The bane of drag and drop Visual Design IDEs like those in Visual Studio or Bindows or NetBeans is the huge and lengthy set of properties that a developer has to sort through. Hence the call for wizards and a 80-20 display of the most important properties. Show the top 20% [say 3-6] properties that get changed most of the time- hide the remaining 80% of the infrequently-changed properties under an Advanced or More button that on-click displays those properties.
4)The Help and documentation for Designer is sparse – This is notable because the EXTjs has one of the better documentation sets for its framework [only DHTMLx is comparable]. But creating a Web UI can become complex quite quickly – as the the number of properties, methods, and events associated with a component are non-trivial.
5)There is no simple way to change CSS color and design templates for EXTjs – DHTMLx and jQuery, two very good rival JavaSCript frameworks, have the advantage that it is relatively easy to change the look and feel of a widgets in a GUI design using their styling templates. I had hoped that EXTjs Designer would address this issue; apparently not so.
So these 5 points indicate a measure of caution about EXTjs Designer. Of even greater concern is the following:
While testing various design and deleting components or widgets, I found that on occasion EXTjs Designer got terribly confused at what was on screen and available for use. The following error message appeared several times in a half day of testing. It finally got to the point that I would a)save the project after adding 1 or 2 components and b)I would immediately backtrack one project whenever I got such a message.
Now EXTjs appears to be built on the Adobe AIR model because during the testing a new update was pushed twice in 4 days. During this period the number of Object errors notably declined. If one thing is impressive about EXTjs is how quickly the organization responds to error conditions and/or security risks. I suspect this ethic will be carried through onto EXTjs Designer.
Summary
EXTjs Designer is already a drag and drop Web GUI prototyping tool of no small capabilities . It really brings to life the power that is available in the EXTjs JavaScript Framework with its tight and speedy set of widget and components. A graphic designer can layout the look and feel of a project in a much shorter period of time and then press the Export Project button and have a web developer fill in the enabling JavaScript and CSS code that will bring the Web GUI fully to life. Now given the rapid development of iPads and 2nd generation Netbooks, it is speed of delivery for the Web 2.0 Internet which becomes ever more vital. EXTjs Designer certainly targets that issue.
But as noted above, for Web Developers EXTjs is missing 4-5 key ingredients to make their tasks easier and quicker. In fact, with EXTjs Designer, graphic designers could easily fall into the False Expectations Trap – “I finished my part of the project in 2-3 days, why cant you web developers do the same?”. Well, EXTjs in release 1 is Not There Yet for web developers. But having watched the very rapid evolution of the EXTjs framework over the past 2-3 years or so, I suspect that they will be able to stand and deliver in fairly rapid order for web developers what they have done for web graphic designers.
I tried it and was wondering how I would add event-listeners and handlers to the generated code. In forum for Ext JS Designer there are some design-examples from the developers, but no example at all for how-to add code without messing within the ui files. Any help here?
First, the ability to add event-listeners and handlers is not in the EXTjs Designer and rightfully so – this is pretty advanced coding and the developers of EXTjs Designer have a lot of other issues on their plate. But I suspect simple generated templates for event handling [users change the commented text or fill in the blanks themselves] will appear in good time. So second, I would suggest you take a look at the EXTjs demos like Treeview, Dataview, and Menuing for examples of “how to do event handling in a UI context. Also there is a good book from Packt which covers the problem – EXTjs 3.0 Cookbook.
I was initially very excited about the designer, and still am to some extent because I have no doubt that additional features are forthcoming, but the show-stopper for me was the inability to edit the code and have the changes reflected in the designer. I had intended to import some existing form setup and have our graphic designers make modifications but the one-way nature means I would have to recreate the forms in the designer first. If only I had the time!
Thanks for providing a thoughtful review of Designer, it’s great that you took the time to put it through its paces. In its initial release, Designer is for existing Ext developers who already understand Ext conventions (although Designer can be a nice way to see what kind of code you should be writing from scratch.) But let me address your specific concerns.
1) Yes the development of designs is one way, in that you have to work from the project file (.xds) rather than the emitted javascript files. For Designer 1.0, we wanted to build a really great interface builder, but it’s not supposed to be an IDE or a visual app developer where you can swap between markup/code and rendered UI and work in either.
2) People either like Wizards or think that they’re a hack to cover up poorly implemented user interfaces. We’d certainly like to make it easier to hook up the datastore wiring, but we’re not sure whether wizards are a good way to do this. This is something we’re going to get user feedback on.
3) The 80:20 progressive disclosure UI is a very valid strategy for simplifying interfaces. Right now the Designer is quite flat in its property presentation.
4)I think you’re being generous in saying the help is sparse :-) We have a project spun up to provide more detailed help and a smoother on-ramp for new developers.
5) Many users have asked for easier themability, particularly for the most common theme customizations like colors. We definitely want to make this easier in the future.
Michael –
Regarding (1), Oneway Design, I appreciate the trade-off in going the extra long-step that is involved in delivering robust two-way design/development. It is certainly non-trivial and could easily endanger getting a very good UI/EXTjs Design tool out the door which would be the community’s loss. And remember changes to component/object properties are reflected in the Design. That is why (3) the 80:20 rule and (4)documentation are important. I will be watching the Designer as it evolves over the next few months and shall do an update review when important releases are made.
Jacques Surveyer
Thanks Jacques! We’ll ping you when we think we have made good progress on these items.
Amazing tool ..
I have been waiting for this release since a long time
Thanks for good information.really help.
The 80/20 thing really isn’t a big deal given the existence of the “hide inherited” button in the attributes. Some CSS control, round-trip editing, and placeholders for even handlers and plugins are by far the most important to me. The better the other stuff, the less the need for round-trip editing.