Tags
People
Badges
Help-
CORE FRAMEWORK
FEATURED COMPONENTS
-
RESOURCES
-
LEARN ZK
RESOURCES
Our company switched to the ZK Framework in the Fall of 2011, shortly after Adobe announced it was kicking Flex out the door. Overall, I really like ZK and there is a lot going for it. But, it's its deficiencies that I would like to point out here in hopes that the ZK team puts some emphasis on correcting them.
First, it has become abundantly obvious to me, during my 30 years as a software developer, that very few developers have any sort of eye for UI/UX. Give a developer a nice set of components, and they will still manage to produce butt-ugly screen designs that look like a five year old was let loose on an IDE. The sad part is, even those developers who think they produce nice looking UI, don't.
And, this fact really demands a separation of concerns where you can split a project out into separate job positions: UI/UX designer, front-end developer, server-side developer, etc. And so, the strength of ZK, wherein each UI Object has a client-side widget and server-side Java component, which allows the business logic to all securely reside on the server, also becomes its Achilles tendon. In other words, it's next to impossible to separate concerns in order to leverage skill specialization.
We had a developer "finish" a project recently, but upon viewing the results, it was obvious the screens were in desperate need of professional help. And so, we outsourced the screen design to a company that specializes in beautifully crafted web design. Here is where the problems become evident. In order for them to design and provide the graphics and CSS, we really had to turn over to them the entire project (WAR file) and hope they had someone smart enough on staff who could come up to speed on the ZK framework, get it installed, deploy the WAR file and be able to run it well enough to make appearance changes. In reality, screen design for a ZK app requires a running instance of your project within a server container.
The next problem that the designer, whether you have it done in-house or outsourced, is that the ZK provided themes are way too damn complex. The ZK team should learn that flexibility breeds complexity, which in turn is counter to the initial goal of flexibility in changing the theme. Simplify it! No CSS should be that verbose and complex. It's ridiculous. The most frustrating part of ZK is making simple appearance changes.
Even after paying about $12K for this design work, the deliverables could only be categorized as modestly "OK" in terms of screen aesthetics.
ZK is a great framework for the few of us who can actually do both front-end and server-side development, and do both equally well. But, my mistake in choosing ZK was assuming that my junior developers possessed the same ability. And when a developer doesn't, solving the problem is nearly insurmountable.
It is my feeling that, until the ZK team fixes this dilemma, it will never receive the wide adoption that it otherwise deserves. I have made this suggest/request before, and I repeat it again. STOP everything else you're doing with ZK to provide more functionality, and dedicate your team to making a better IDE, which allows for separation of concerns. Your framework gets a 7, but your visual studio gets a 2. Put your emphasis in where your deficiencies are at.
Ron
Hey rdgrimes,
First of all I would just like to say thank you very much for your detailed feedback, it is much appreciated.
I would like to address some of your points and tell you what we have planned, which will alleviate some of the CSS pain point that you identified.
Firstly, just as a bit of background let me (quickly) elaborate on why the DOM structure & CSS is a bit more complex than what you would be used to. ZK 6.5 is a recent release and as such is one of the only "recently released" frameworks that still supports early IEs (such as 6).
The reason for this is two fold,
Now, that's the reason that in ZK 6.5 IE 6 support was kept, as with such a large amount of the customer base still providing for IE 6 while needing extra mobile functionality it was virtually impossible to drop. Of course with success comes the down side in that in supporting a multitude of browsers (flexibility) things can get a bit complex client side, which isn't good for the reasons you have outlined.
That is why I am pleased to tell you that ZK 7 will be introducing a new theme based around CSS 3 to simplify the client DOM structure and CSS meaning it is easier to customize. In addition to this, not only is the new DOM structure simplified we are also basing some of it around bootstrap which should give the designers something easier to work with enabling a separation of concerns which was harder in 6.5. Thus any design work (in house or outsourced) should be much easier to implement, in fact those designers should be able to implement it themselves.
One thing I would like to follow up with you is your comments on ZK Studio, what would you like to see in ZK Studio? Is it some features that you believe are missing, features that need to be improved, or both...?
Thanks again, Tim
I am sorry to add my comments here. I love ZK and i hate whenever i saw examples using zscript. Almost all the official ZK Examples/tutorials/forum explains the concept using zcript only. But at the same time, ZK Documents saying zscript is not recommend for production. If that is case, either ZK Team should not explain any concept using zscript or after each example, they have put the warning saying, using zscript is not recommended..."
In the ZK Forum, i saw ZK Developers replying using zscript, which should be avoided in the future.
Very important, when new people start learning ZK, if they found solution for their problem, then they will never mind using zscript because they might not known the performance issue of zscript at the time of copy and paste the example into their project.
I hope all the future examples will not contain any zscript code.
Secondly, i should agree with rdgrimes on the CSS part. During my tutorial, i found creating the theme folder does not make any big difference.
One of my problem in CSS is, in border layout, i try to set different color for split using sclass. But i came know understand that is not possible, because split is not a separate component.
Tim,
The ZK teams' plans for version 7 sound great, and should alleviate a lot of the problems I outlined.
As for what I would like to see in the Visual Studio, the biggest problem is you have no idea what the screen is going to look like until the project is deployed inside a container and running. I realize part of the problem is that the model for each component is supplied by the associated controller/vm class, and so, until the controller/vm supplies that model, it's hard to lay out the screen visually for the designer. And, of course, this gets us back to separation of concerns. How can anyone design the screen, in terms of separation of concerns, unless the controller/vm has been fully developed to fill in the model data that the view relies upon? I would suggest the following:
Have a side panel on the visual editor where it has a section for each component on the screen. Below each listed component in the side panel, show the available attributes the component could have. Allow the values to be selected or filled in with mock up data, dynamically rendering the visual editor appearance accordingly. This allows a designer to try out different options and see what the screen would look like if various attributes and/or models were applied. And, this allows them to do so without knowing how to wire up some zscript objects to bind to the view components and without knowing how to write and wire up a controller/vm to the view.
Changes to the visual editor's side panel would be automatically be reflected in the view code, and attributes filled in on the code side would automatically reflect in the side panel of the visual editor.
I believe this type of visual editor would allow a designer to much more easily do their job without needing all the server side code in place first, or without knowing how to wire up zscript object for temporary binding to the view.
Just my opinion. Maybe others have better ideas. I've tried to offer suggestions that take into account the difficulty you have of providing a good visual editor in the context of an MVVM environment.
Ron
@Senthil,
The suggested best practise of not using zscript exists in FAQ, unfortunately it is hard to find so we are looking at making it more obvious at the moment.
@rdgrimes,
I am really pleased that you are excited for ZK 7.
Regarding Visual Editor thanks for outlining your suggested functionality. I will forwarded this on to our ZK Studio team. Currently the team is working with our ZK team to make ZK 7 the best it can be. So I think once ZK 7 is released with the new themeing it is a good time to explore the possibility regarding visual editing in ZK Studio.
Thanks, Tim
Asked: 2013-06-22 18:33:54 +0800
Seen: 60 times
Last updated: Jun 27 '13
