There are so many properties to navigate, in fact, that the standard method of locating them is to search for them by typing their names into the Filter box. Of course, this means you need to know what the specific property you're looking for is called and under which level of the hierarchy it is located. At times, the process reminded me of nothing so much as editing the Windows Registry.
I would also have liked to see more wizardlike features to assist in setting up the most essential properties for widgets and components. As it stands, when you create a new component, Architect populates it with a dummy name, such as "MyDataStore," and fills its properties with default values. These will almost always be useless, so you must navigate to each property and adjust the value to what you want. Then when you want to link components, you must cross-reference component IDs in each others' properties, again by hand.
This can be incredibly tedious. Building one of Sencha's tutorial projects took me about two hours. Maybe that would be incredibly fast if I was really building a Web app from scratch, but I was just following a series of steps. Worse, when I reached the end of the tutorial, the app didn't render properly in the browser, leaving me to wonder which of the many property values or code snippets I had mistyped.
Switching over to the Code view, you can see how Sencha Architect generates code for all the things you create in the editor. The code is pretty clean and readable, all right, but that's really because of the Ext JS framework. If I wrote the same app by hand, I expect my code would look identical.
In fact, editing an Architect project can be so laborious that I have to question some of its claimed advantages over traditional development methods, boilerplate code and all. When I have to configure long lists of cryptic-sounding properties, is it really more efficient to do so by mousing back and forth in a GUI, rather than typing into a text editor? Architect just seems to trade one form of drudgery for another.
UI designer, meet MVCIts advantages for UI developers are also questionable. For example, Architect supports the Model-View-Controller (MVC) software design pattern, which is popular with back-end Web developers; Ruby on Rails, for example, is based on MVC. But front-end developers tend to be less concerned with such architectural matters, and they may have a hard time understanding how to connect Models, Views, and Controllers, or why. They're more interested in the visual aspects of Web development, which aren't really Architect's strengths.