Granted we have only had access to the trial version (waiting for sales to update pre-orders) for a couple of days. Even with this limited amount of time we are still having trouble seeing exactly where this fits into our development life cycle. Now before I dive into our feedback I wanted to call out that I am happy we purchased ExtJs Designer and have no regrets in pre-ordering. Anyone that can look towards the future should really consider supporting ExtJs to allow them to continue improving this tool. I also understand that this is version 1.x and that a public beta was not conducted. Regardless of that choice, it was released for production use, which is what prompted our feedback.
Throughout this post I reference "a design tool" and a "mock up tool". In this context I associate a design tool to something similar to products like PhotoShop or Fireworks, which allow you to create something 'complete' from scratch. For a mock up tool I reference Balsamic, having personal experience with this product, as something that lets you visually represent an unfinished design.
Use Case 1 - From the Business Analyst
For us, at the start of our development process, we have the role of Business Analyst(BA), which is the person looking at all of the requirements and features, writing user stories, helping plan sprints, things like that. We all probably wear this hat in some fashion either as a Freelancer, or simply when we work with our customers to gather the requirements and building out your backlog.
So far they like the tool as it makes creating Extjs mock ups very easy. The issue comes down to the usability of what is created. An example, the BA using ExtJS Designer puts together a mock up of a simple Viewport with a border layout. You have a few buttons in West and a tab panel in Center. Nothing complex as far as design goes.
After using the designer for the first time here is what happens:
1. Creates Mock up in ExtJS Designer
2. Take Screenshots for each 'page'
3. Either printing or using a graphics tool, Draw what the expected actions or behaviors the UI would perform. Such as saying that Click on "Button 1" on the left, which should open a new tab in the center, which then contains the view from page 5 (or screenshot 7).
4. Deliver these designs to the developer, through your ticket tracking system (or email), who then programs them out to have the behavior
Even when you look at the aspect of working directly with your customers, either showing them or asking for feedback. While you now have pretty ExtJS designs, how much of your time is spent answering what this button is supposed to do, or how this form will work. How many additional notes, paperwork, or post production ExtJs Designer project work (ex. Fireworks, PhotoShop) is required to get right point across.
We currently use Balsamiq as our mock up tool. This is not a 'plug' for this company, because I really see these two products solving different needs. Balsamiq allows for Drag and Drop UI mock ups, which allow you to link between mock ups. Meaning that you click on 'button 1' and that links you automatically to 'mock up 2', or to display an error message, etc. This allows for our BA to toss together a full interactive UI (with no coding at all), and place virtual 'post-it' notes to explain more complex behavior.
The trade off is that this comes with no code. The developer must 'start from scratch' to create these screens and behaviors. Unlike with ExtJS Designer, you get code, but that brings me to point 2.
Use Case 2 - Maintainable
1. ExtJS Designer is used to create a design
2. Developer takes that, programs and builds out the behaviors, listeners, back end integration, etc.
3. You finish with your sprint with the developers delivering what was asked for as well as cleaning up the UI a bit more, etc. You are now out beta testing the application.
3. Scope Creep happens and the BA (from the client) wants to change the design around to account for the new changes. Now comes the dilemma:
A. Do you work from the initial ExtJS project, which is no longer the same as what is in production,
B. Redesign the Mock up to reflects the new requirement,
D. Not use ExtJS Designer,
4. Now as a developer you get one of the options above...
A. or B. Outdated code that didn't reflect the new changes from Production and either way you now have to sort through new code that you have to refactor into your old prodction code. Or you simply have to use the designs as examples and reprogram it.
D. or E. Really removes the benefits of ExtJS Designer.
The second half of this comes from the developer who wants to use this as a tool in their workflow. I know that in my experience developers 'should be' Testing, Programming, Verifying Tests, Refactoring, and Repeat. Even in other development methods programmers are always coding and refactoring. If I use ExtJs Designer I cannot really do that, since as soon as a I program anything after the initial designer export, I cannot go back in and make changes. Let's say that I make a bunch of changes like adding listeners, or other behavior to my objects, and then I want to go back and add a few more fields to my form, update the layout or tabs, I now have again two branches of code I have to manually bring together. Copying and pasting the differences. You can see the time overhead that comes with this as it is today.
In a real world environment that last thing you want to do is maintain more code. It's costly to the entire development cycle. Reinventing the wheel or creating something that is not reusable(or circular) negates some of the benefits of a tool like this. Tools like this should remove overhead to the process, not add to it.
In short, I hope that this shows how important it is for ExtJS Designer to import code that developers create to truly create value across the life cycle of the project. Today you are left with, First time designs risking the overhead of keeping everything up-to-date, or keeping your use of ExtJs Designer as a code helper to simply give a developer the framework of code for components, and the overhead of merging.
Use Case 3 - Representing Abstract
I touched on this briefly in Use Case 1 with the ability to add non-ui 'notes'. A key issue that I can see in the future is the balance between a design tool and a mock up tool. Currently your site lists that your target audience as "business managers and non-programmers". The problem is that these roles don't often know what exactly they are looking for, because they are trying to analyse and interpret customers who are not sure what they want... Now in trying to find a use for ExtJs Designer I feel caught up in an "Identity Crisis" and asking myself should I be trying to pitch this tool to upper management as a Mock up tool, or as a Design Tool?
Let's say for a moment that a customer has two requirements:
1. "As an Web Administrator I need a way to see a list of all registered users."
2. "As an Web Administrator I want to be able to group users by department."
The BA might say, "Well that is a great way to use a data grid and I have seen a lot of websites out there that use drag and drop, so you should be able to drag and drop users into group buckets on the same page." Trying to use ExtJS Designer the BA might find that you can simply drag and drop a data grid into the workspace, then wait... looking through the buttons, you cannot find a way to create drag and drop targets. You find yourself thinking that "...I thought that ExtJs could do drag and drop, well I guess not. I guess I will just have a pull down menu here for setting the group." and move on. You might also try and ask one of your developers directly, who would say yea we can do drag and drop, you just can do it in the designer. And now you are left having to partially design it using ExtJs Designer and for some parts using paper, or words, to define the requirement.
We have two things here:
First we have the feature gap that exists between ExtJs and ExtJs Designer. This can results in a non-programmer just not knowing what can be done with ExtJS, and in turn missing out on key benefits of using ExtJS. How does the user of ExtJs Designer know that you can have form validations, charts, listeners, etc. How much additional training is expected of a non-programmer, should they know to look at the ExtJs API, Samples Page, etc. If this is a design tool like PhotoShop, just think about how much most of us don't know about what can be done in PhotoShop, (Learning Curve, which needs lots and lots of documentation and training materials to help with adoption.) If this is a mock up tool why should I use this tool over others on the market. (Sell me on the benefits and let me know what you are going to solve my needs)
Second, you also have no way easy way to represent abstract concepts. Sure, some of this is a training issue. Teaching the non-programmer to create a panel and put a label inside of it saying 'custom widget here, see ticket #7545', or what ever the best practices might be. And this compliments my confusion over is this a design tool or mock up tool.
I know that it's always so much easier looking from the outside and think you know best. With that note, here are a few non-personal feedback.
1. If you do not already practice agile software development methodologies, such as Scrum or XP, I strongly recommend that you look into this for the future. I personally have been part of a startup companies adoption and an enterprise 100+ developer plus web application company. In short, both adoptions were successful and you would be amazed and how quickly our releases were on time and actually met customers needs. I could go on about this and would love to share if interested, send me an email.
2. Provide a few examples of where you see ExtJS Designer working in the Software Development Life-cycle. Create a couple of user-story based blogs or studies on how this would be used in the real world. This let's people like me really understand the expected use of the product.
3. In your next release take an internal project, maybe something that you have had in the parking lot for ExtJs Samples. Or even better would be to survey ExtJs users on another 'Sample' they would love to have. Then run through a full development cycle, using ExtJs Designer as the central focus, how is it used, what gaps or problems were found, then document it and improve. It's the time old saying of 'eat your own dog food'.
4. Implement an 'Idea' requirements solution to get more feedback from your LARGE community. A great model of this would be SalesForces idea exchange "http://sites.force.com/ideaexchange"
I hope that this is taken as constructive feedback because we are really glad that we have this tool and are really excited to see how it grows in the future.