- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
Information Visualization tools
Some would argue that Web 2.0 is a social revolution, not a technological one. Social networking tools such as Blogs, Wiki's, bookmarking and tagging sites, Mashups, and APIs allow collaboration between users and communities of a much greater quality than ever before.
As these new tools allow users to share and collaborate in ever more sophisticated ways, social data increases in quantity and complexity.
Emily Chang has posted about a few innovative tools that help users navigate that data...
Visualization and Discovery
Business Rules Management and Testing - Avoid the “Mystery Box”
I apologize for being tardy this week with my post. The truth is that I just got my hot little hands on the latest Blaze Advisor with the new RETE III engine and have been heads down testing it out. It's too soon for me to really say much about it other than "it's fast." Man is it fast. That's not a benchmark, mind you, just an impression from years of working with rule engines. OK, more on Blaze later.
OK, so over on The Road Hits the Rubber, Peter Lin muses on the shortcomings of Business Rule Management Systems:
- many users have very specific ideas about how to manage rules, but most don't bother using it. This applies to products from iLog to other vendors.
- users who actually manage rules actively have very specific ideas about how it should work. In this case, existing tools don't match what they want.
- an all purpose rule management system must be extensible for it to be useful. I'll go into this in greater detail
- many companies using rule engines and business rules have poor process in place. the typical horror story is the business analysts deploy a rule without testing it and the production system crashes. It's frightening how many companies do this.
- many business currently using rule engines are not using RETE algorithm and actually don't bother running compliance due to performance. this is actually very common and many businesses use performance as an excuse not to run compliance.
Here, here. Many companies look at the BRMS offerings of their vendor and say "we don't work like that." Rules end up being dumped out into an export format and checked into a source code repository. This is no way to manage rules.
Peter suggests a number of solutions to the above problems. There's lots to digg into here but I'd like to focus on one thing and take issue with him a little bit. The last two points on testing and compliance are, in my opinion, a very important part of what a BRMS should deal with. Peter doesn't agree:
Many sales guy ask for features like rule validation, spell checking and all sorts of stuff, but that isn't part of managing rules. That's the authoring of rules. To me authoring rules includes things like validation, profiling and application testing. Managing rules is a different discipline than writing rules, so it's best to separate the two activities and provide a clear integration between the two. When an user wants to save a draft of the rule, it sends the draft to the BRMS. If someone like his supervisor wants to review the rule, he should be able download it from the BRMS server.
From my experience, you are managing rule sets, not just individual rules. If you write your tests and run your validations at rule authoring time, you are vulnerable to someone deploying an invalid or nonsensical rule subset to a production system. Rule set validation and regression testing should thus absolutely be a part of the BRMS; adding, subtracting or modifying a rule into a large system can have many unforeseen consequences and unit and regression testing of rules and rule sets is one excellent way of addressing this problem.
Maybe I misunderstand what Peter means here by validation. I take it to mean that you are checking an entire rule set for correctness within a context; that context may be a particular dataset or a particular set of tests. A rule set that is correct for a population of Medicare patients may not be correct for a set of Medicaid patients. Thus the tests you perform on a rule set are specific to where you are deploying that set.
Taking a page from the OO world, writing unit and regression tests and testing for code/rule coverage should be built into the BR system life cycle. If you are authoring a new rule, you are likely doing so to change the behavior of the system. You should have a clear idea of what that change consists of and how it would be expressed in a test case or regression test. Otherwise, if you can't specify what sort of change in behavior you are trying to achieve, you have no business modify the BR System to begin with.
Lack of aggressive and rigorous testing in rule management leads to what I've termed the "Mystery Box." This is the rule based system whose inner workings are so mysterious that no one can tell how it arrives at it's conclusions or whether those conclusions are correct. Imagine a company where fixes in data quality or rule set correctness would result in newly correct behavior for a rule-based system; they would face a crisis because they had been feeding their customers incorrect information for years. Don't let the "Mystery Box" happen to you.
Topics: Business Rules
Another GWT Tutorial
Update: I've posted 36 GWT Tutorials, a more up-to-date list of GWT tutorials.
I know I promised this would be ZK week, but my code reading is going a little slower than I expected. So let me work in some more news about GWT. I know, I know, you're sick of GWT (or maybe you're not). But there's a nice new tutorial over at java.net. It's called Kickstarting Google Web Toolkit on the Client Side and it provides, in increasing order of sophistication, three example GWT applications: a simple "Hello World!" app; an amusing Zork type adventure game ("unlock door", "go north", "read plaque", etc.); a cool little animation made up of a few simple yet effective pieces.
This is probably the best GWT tutorial I've see to date as it actually tries to do something beyond flinging around some labels and text fields. Of course, the tech publishers are probably hard at work on a book that builds a non-trivial application with persistence and rich features. This will have to tide you over until then.
Topics: Ajax Examples, Ajax Frameworks, Frameworks, Games, GWT, Tutorials
Extending the desktop metaphor
A way cool product in the maiking...
This interface looks and acts much more like a real desktop.
But is it just eye candy, or is it a real advance in digital usability...
Footage of the product on Google Video
Topics: Desktop, Rich Interactions
Rethinking the Help System in an Ajax World
In desktop applications and the new genre of Ajax applications it's possible to provide contextual information to the user. This is typically done one of two ways. Either real estate is devoted up front to the display of this information, or a pop-up (or slide-in) of some kind emerges.
The ability to contextualize information physically suggests the necessity to rethink the creation of the help system. Not only must we consider what the information must be, but also when and where it will likely be accessed. The help system truly must be a system, not just an encyclopedia of the features of the tool (that is still a good thing to have, nonetheless).
The down side of a highly contextual help system is cost. Someone has to design it, not just write it (you have to do that too). There may be a good middle ground, though. Consider providing specific help access points contextually in your application for the things users are most likely to get stuck on. Provide opportunities for assistance, advice or suggestions in context where the benefits are significant to the task at hand. Let the user easily get the information, and get rid of it when their needs have been met. This approach can deliver value to your users, while keeping the creation and maintenance costs reasonable.
The Hazards of Exposing Business Logic on the Client
Via Ajaxian we get an object lesson in the dangers of exposing business logic in the browser:
Beau Hartshorne of Snipshot (formerly Pixoh) says "massive chunks" of Cellsea code are identical to Snipshot. "This is not an accidental inspiration. Check out the cropping code, the resizing code, and so on. We've also noticed that portions of their website are also stolen directly from ours ... We are contributors to MochiKit open source project. However, the code in question is proprietary and was taken directly from out site."
Can I say "I told you so?" I've blogged about the danger of Ajax and Leaky Business Logic before. What is the danger here and the lesson the be learned?
- Don't put your crown jewels in the browser. See if you can't lock a fair bit of your business logic on the server side by using a server-side component framework like Echo2 or ZK.
- If you're going to deploy meaningful applications in Javascript, do what people have been doing with script source code for decades: obfuscate. You can do something simple like renaming all of your variable to one or two character names, or you can use a code generation framework like GWT or Morfik that produce unreadable code from the beginning. Be forewarned that code generators can be vulnerable to decompilers -- in short, if someone knows how GWT generates it's code, you could possibly reverse the process and produce the original source code.
- Build in anti-theft mechanisms. This could be something as simple as a method that checks to see that the url the application is running on is the correct one, otherwise display a nasty message. You could make this as tricky and complicated as you like, all the way to encrypting big chunks of code with the website url and only decrypting them at runtime.
- Hold out for "byte compiled" Javascript.
A combination of all of these may be what we end up with. I'm not sure I'd want to run any script in my browser, though, that I can't understand. Still, you would hate to be the victim of code-theft as has apparently happened to Snipshot.
How similar are these two programs? Well, Cellsea offers a bunch more functions, but they do look very similar, both in terms of the UI and the underlying code. The original Snipshot is here and the knock off here. You be the judge.
If you are really hungry for a good AJAX image editing app, the best of the bunch of them may be Phixr, which gives you preview, the ability to marquee select for certain operations, etc. Slick, even if the UI is a bit jumpy.
An Interview with ZK Creator Tom Yeh
Anyone who has been following the development of AJAX frameworks has heard of ZK, the server-side component GUI framework that allows you to write applications like you would a desktop app. It has become one of the most popular projects on sourceforge and has been nominated for a 2006 Sourceforge.net Community Choice Award.
Recently I talked with one of ZK's creators, Tom Yeh of Potix, about the Framework's popularity and future.
ZK Background
DK: How did you come up with the idea for ZK, i.e. an AJAX framework that allows you to write webapps like you would a desktop app?
TY: As I mentioned in http://zk1.sourceforge.net/faq.html#Why, it is the result of frustration.
I was a fan of thin-client computing since leading a wonderful team to develop Network Computer and Window Terminal in 1995. I truly believe in the so-called utility computing. Accessing applications should be as simple as using tap water.
It is crazy that someone should carry tons of water when traveling, since tap water is available everywhere. However, we still travel with notebooks, even though Internet connectivity is everywhere. Similarly, the Web edition of MS Outlook has been available for years, but we are still using the desktop version. Why? Frustrated user experiences and excessive development costs. In other words, it is too costly to develop a Web UI from scratch or add-on to 'legacy' apps, and people won't use the Web UI even if it is provided.
After trying different ways to apply Ajax in the projects on which we consulted, we found that applying Ajax at the client side, as most frameworks did, only solved the half of the problem -- though it did result in a lovely interface. That is why ZK was born.
DK: Who is Potix?
TY: Potix is a consulting firm providing expertise in Web development and project management. We also develop applications on an ODM-basis. ZK is the consequence of this work. However, due to strong demand, we mainly focus on ZK now.
Potix is also a house of old dogs. Most of us have more than 15 year of experience, ranging from developing Windows/Linux/Web applications, to embedded OS and GUI frameworks. ZK is my second OSS project; the first one, called OpenPam (GUI for embedded devices), was not very popular.
DK: How are you planning on making money with ZK? Nextapp, the makers of Echo2, sells an Eclipse plugin for around $400. Is that a business model you are examining?
TY: Dual license (as MySQL did). You might also take a look at one of my posts: http://sourceforge.net/forum/message.php?msg_id=3605162
Other Frameworks
DK: Echo2 seems to be the only other server-side AJAX framework out there. How would you compare yourself with Echo2?
TY: Echo2 assumes UI designers are Swing programmers, while ZK assumes many of them are not programmers.
Markup languages, like HTML, XUL and XAML, scripting languages, like PHP and Ruby, and the object oriented approach are the three most important developments since GUI was introduced. Unfortunately, Echo2, WebOnSwing and similar frameworks only focus on the object-oriented approach.
In addition to BeanShell, we are looking at the possibility of using Ruby and PHP in zscript. It looks to be, so far, quite feasible.
DK: There's lots of talk now about the Google Web Toolkit. Do you see it as a competitor to ZK or a complement?
TY: Both.
From a technological viewpoint, it is a complement. GWT is a client-side solution and quite good for developing Ajax components. On the other hand, it is never a good idea to replicate the business logic to the client, which eventually brings us back to the maintenance headache of fat clients. In addition, loading huge JavaScript files into the client and executing them there is not fun at all. At the end, you need a server-side solution to handle the business logic and presentation tier.
It would be great if we can leverage GWT's power to simplify the effort of component development (as we did with DOJO and FCKeditor).
From a perception level, users might see it as a competitor. Google is now at a sweet spot with plenty of resources and a good reputation, as Microsoft was in the 1980s. Developers love to explore any kit Google puts out there and exaggerate what it can do as if Google was the first to invent it.
DK: Do you envision developers writing ZK components using GWT?
TY: Sure, GWT does a good job for non-JavaScript programmers who want to develop Ajax components. I expect that some results of this will show up in next few months.
However, what makes Ajax programming difficult is not JavaScript itself. Rather, it is the incompatible and buggy API (to communicate with DOM). The ability to do Java-to-JavaScript is important, but I am also hoping for some benefits from the standards efforts of OpenAjax.
The true value of ZK is its architecture. We look forward to adapting components to ZK as decent (client-side) Ajax components become available.
DK: What other AJAX tools, frameworks or technologies do you think are noteworthy or interesting?
TY: DOJO has an amazing set of components, though it is too heavy (one of the reason we didn't build the ZK Client Engine upon it). Atlas has great integration with Visual Studio. Anyone who wants to provide an authoring tool should take it as an example. Google Spreadsheets is an excellent Ajax application. You should unplug the network connection and see how it reacts, though. It's cool nonetheless.
Strengths and Weaknesses
DK: What would you say are the strengths and weaknesses of the ZK framework?
TY: Strengths: boundless. But seriously, great richness and excellent productivity, if we can put in a sentence.
Many of ZK users appreciate that they can design a rich Web application without programming. Many have thanked us for the intuitive event model and feature rich components that have saved them countless hours. Many enjoy the power of prototyping so they can change the look and function right in front of their customers. For more information, you could take a look at the executive summary (http://zk1.sourceforge.net/wp/ZK-exesum.pdf).
Weaknesses:
- Stops working if the connection is broken. It would be better if a subset of functions still worked (such as read only viewing).
- Round-trip latency, though hardly observable. To minimize the effect of this, we plan to, in addition to Client Side Action, add visual effects that execute solely at the client and notify the server only when necessary.
One other weakness shared by all HTTP-based solutions is the lack of Server-side push. Though someone has implemented so-called "reverse Ajax", it introduces too much overhead on the server. This -- server-side push -- is the next important step beyond Ajax.
DK: There aren't any production applications out there using ZK. Do you see that as a problem and, if so, what are you doing to address it?
TY: According to the profile of our customers, adopting ZK is still in the development (and evaluation) phase. By and large, adopting Ajax for most companies is still in an early stage. It is just a matter of time. I'm not really that concerned about it as long as the growth of ZK's acceptance is strong.
DK: Right now, the framework doesn't seem to allow for easy customization of the look and feel (window color, font, etc.). First, is that correct and, if so, do you have any plans to address it?
TY: Not correct. The look and feel are well separated by CSS and molds. What prevents users from customizing the look is the lack of documentation and samples. Also, the customization of the sophisticated components is sometimes not intuitive. It forces users to look at DSP files (the templates used to generate HTML tags). We realize this is an issue and we will provide documentation in the Developer Reference guide.
DK: I've noticed in the code that you spawn another thread to handle events. Can you explain the design to me? Also, how does this fit in with the Servlet standard and doesn't this make it difficult to cluster a ZK application if the user session has non-serializable information and context?
TY: It is common that an application has to confirm with users about, say, whether to delete a file. It is unbelievably costly for Web developers to implement such functions. Why? Users get no response until the servlet has completed, while the servlet requires user's confirmation to decide whether to proceed further.
There are many solutions to this problem, but the most elegant one is modal dialogs. ZK is one of the first Web framework that really enables the server-side modal dialog. The magic is to process events in another thread. Then, users can suspend and resume the processing anytime they like -- including but not limited to modal dialogs.
It does make clustering difficult if there is a pending thread in a session. We are working on the serialization issue now. A basic idea is to send the application a notification, and it can decide how to handle pending threads. Of course, if there is no pending thread, there is no notification at all.
DK: What is your favorite ZK feature?
TY: Macro components, the threading models, and zscript.
DK: Are there some cases where you wouldn't use ZK to develop an AJAX-based web application?
TY: Hard to imagine unless clients want the application to be functional even if the connection is off. Oh, action games, but it might not be a good idea to use Ajax there at all.
DK: It doesn't appear that you are using JUnit in the ZK code. Is this true? And if so, why?
TY: Only common utilities are tested with JUnit (refer to pxcommonTest in SVN). I am still thinking about which is the best way to test ZK components. We will come out with something in the near future.
Future Plans
DK: What is the biggest feature enhancement request you are getting from the users of ZK?
TY: Safari support and design patterns. By design patterns I mean information on how to really write an application with ZK. An illustration with Pet Store is a common request.
DK: On your road map you mention plans to provide a mobile version of ZK. First, what is the time frame for this? Second, how are you planning to do this architecturally? Can users write one application and dynamically re-target their apps to a different front end?
TY: We originally planned to provide a J2ME-based client engine, but we are keen on developing a Flash-based solution now. Architecturally, we have to do three things to support a new client: client engine, server engine and components. Users have to do two things accordingly: use a different set of components and adjust their UI to fit into small screen. We will keep the component API very similar (and also provide common interfaces that make developer's code polymorphic).
It is possible to let users use the same set of components, where components would be smart enough to detect the client and behave differently. However, we're not considering this approach because it makes the development and maintenance of components too complicated. Of course, we can use the factory pattern to chose the correct implementation, but it makes the instantiation of a component too complex for most users.
DK: You've stated that ZK is at the interface layer. Do you plan to introduce components that punch through to the data layer, sort of like the .NET datagrid?
TY: Yes. We will add more data-layer utilities, such as zkplus's DelegatingVariableResolver, too. After all, most ZK applications will have to access a database. However, we may not do a similar deep integration as Ruby on Rails did -- I don't like to make so many assumptions about how applications might be built.
DK: What do you see as the major challenges facing the AJAX community today?
TY: There are too many frameworks, such that many users prefer to wait. There isn't even a well-recognized categorization for them (such as server vs. client). A comparison chart or something similar would be very useful.
A standard like OpenAjax will help (at the client side), but I've never seen an alliance really work.
DK: Care to share any other plans you have for ZK?
TY: We are interested in adding mega-components, such as spreadsheet, forum and wiki. Part of the success of PHP is because the availability of plenty of off-of-shelf stuff. We won't develop all of these components ourselves. Rather, we prefer to help other developers deliver them either as OSS or commercial components. We will have a ZK.forge website to promote such collaborations.
Topics: Ajax Components, Ajax Frameworks, Ajax Products, Ajax Tools, Ajax Widgets, Design Patterns, Echo2, Flash, GWT, Web 2.0, Web Development, Web/Tech, ZK
If the hat fits–do you wear it?
I've just completed the first of three days of usability testing for a new educational online subscription product. The multiple sessions are stacked consecutively; the 45-minute breaks I thought were ample in theory seemed to last as long as a single gasp today, as our team fought--not always successfully--an unfolding series of unfortunate technology events.
Still, I love the opportunity to do usability testing. I've been very fortunate in my career in UXD to have always worked in environments that did not create an unscalable wall between Information Architects and Usability Specialists.
If research, including usability testing, can be defined as "diagnosis," and creation, including wireframes, site maps, taskflows, and the like, comprise "design," these two complementary, yin-yang aspects support, validate and enrich each other. I love the opportunity to play both of these roles, to wear both hats. I think it's made me better in each, and takes me back to my early education in arithmetic, where we "proved" the accuracy of any single answer through the complementary operation--the division problem was proved through multiplication, the subtraction problem through addition.
Usability testing diagnoses design. It's the analysis of user reaction as opposed to the creation of user action. Diagnosis looks outward to the users, acting upon the design; design looks inward, to the designers acting in lieu of the users.
Topics: Diagnose, Usability, Usability Testing
ZK - Documentation & Tools
Documentation
The quality of the ZK documentation is very high by Open Source standards. The documentation includes:
- A 13 page PDF Quickstart guide - shows how to set up the demo application and a hello world app.
- A 169 page PDF Developer's Guide - steps you through the ZK framework with lots of small examples illustrating components and concepts.
- A 43 page PDF Developer's Reference. Documents component properties and behaviors. This document is only about 40% complete.
- A 1 page PDF Executive Overview.
- A 16 page PDF Product Overview - gives information on the motivations behind ZK and the architecture of the product.
The reference guide will need to be completed, otherwise developers will be guessing at specifics of components and the ZUML. Also, the documentation on CSS and "molds," i.e. the templates for components, is spotty. This will make it difficult for developers to change the look and feel in any significant way.
Tutorials
While there is a ZK demo application that shows off various components, there appear to be no tutorials or example/reference applications available to the would-be ZK developer. There is a wiki with a how-to/cookbook page, but just like the developer's guide, it consists of short examples, not a substantial application. There is also a port of a struts application over to ZK, but it seems to make use of so little of the AJAX capability of the framework that it can't really be considered a tutorial or reference app. For now the forums are probably the best source of information and support. Also, there is a "small talks" section of the project site that has some bits of information on integrating ZK with things like the Spring Framework.
Usability
Overall the framework is a joy to use. The ZUML makes it easy to do quick iterations -- edit, test, edit, etc. -- without a long compilation step. The ZUML is also easy enough so that non-programmers can compose or modify a UI. Exposing effects such as drag-and-drop, async update, etc., as components or attributes further eases the development of complex user interfaces for non-programmers and programmers alike.
Tools
As of this writing there is no IDE integration for ZK. This is really a crying shame, since the ZUML makes a WYSIWYG UI layout tool a natural fit.
Scenarios – Recording a Day in the Life
One of the simplest and most effective scenarios you can create for an application user (someone who uses an application as part of his or her daily work) is the Day in the Life scenario. It is effective at capturing both tasks and context for using the application.
A series of interview questions can be used to extract the Day in the Life. Some possible questions are:
1. When do you arrive at work?
2. What is the first thing you do?
3. What kind of interruptions do you have?
4. Do you multitask, or finish one thing at a time?
5. How frequently do you use the application during the day?
6. What tasks does the application help you perform?
7. How critical to your job are these tasks?
8. How does the application help you do your job?
9. What does the application not help you with?
10. How much time do you spend during the day using the application?
11. What work is left unfinished at the end of the day?
12. When do you leave?
You can add to this list and modify it as needed. Once you finish your interview, transform the responses into a narrative for an effective Day in the Life scenario.
Topics: Best Practices, Methodology, Personas, Scenarios
Welcome to ZK Week
This week I'll be focusing on the ZK framework. It is one of two server-side component GUI frameworks in the Java AJAX universe, the other being the Echo2 framework.The basic idea behind these server-side frameworks is that you write web applications just like you write desktop GUI applications:
With ZK, you represent your application in feature-rich off-the-shelf XUL and XHTML components, and manipulate them by listening to events triggered by users, as you did for years in desktop applications. All your application codes are running at the server, while the visual representations of components and user activities at the browsers are automatically synchronized by ZK.
Though the idea is to write webapps like desktop GUI's, ZK applications are deployed as standard servlet-based webapps -- just edit the web.xml file, import in the zk libraries, add a few .zul files (ZUML) to the web content and package up as a WAR file.
Overview
A ZK application consists of two parts: a client-side Javascript engine and a server side Asynchronous Update (AU) engine. They interact something like in the following sequence diagram.
The developer's guide gives the following execution sequence:
-
When a user types an URL or clicks an hyperlink at the browser, a request is sent to the Web server. ZK loader is then invoked to serve this request, if the URL matches which ZK is configured for.
-
ZK loader loads the specified page and interprets it to create proper components accordingly.
-
After interpreting the whole page, ZK loader renders the result into a HTML page. The HTML page is then sent back to the browser accompanied with ZK Client Engine.
-
ZK Client engine sits at the browser to detect any event triggered by user's activity such as moving mouse or changing a value. Once detected, it notifies ZK AU Engine by sending a ZK request.
-
Upon receiving ZK requests from Client Engine, AU Engine updates the content of corresponding component, if necessary. And then, AU Engine notifies the application by invoking relevant event handlers, if any.
-
If the application chooses to change content of components, add or move components, AU Engine send the new content of altered components to Client Engine by use of ZK responses.
-
These ZK responses are actually commands to instruct Client Engine how to update the DOM tree accordingly.
You create the UI by writing ZUML files, an XML-based language for specifying the composition of ZK pages and components as well as Java snippets to specify behavior. Here is a simple example of a tabbed pane in ZUML:
<window title="tabbox demo" border="normal">
<tabbox width="400px">
<tabs>
<tab label="Tab 1"/>
<tab label="Tab 2"/>
</tabs>
<tabpanels>
<tabpanel>This is panel 1</tabpanel>
<tabpanel>This is panel 2
The second panel</tabpanel>
</tabpanels>
</tabbox>
</window>
This ends up looking like this:
ZK is just a presentation framework, i.e. you'll have to write all of the business and persistence logic yourself. But it does do quite a good job of providing you with off-the-shelf components and effects:
- Embedded, popup and modal windows.
- Tabbed panes.
- Calendar selectors
- Text input with constraints
- Various kinds of select and combo boxes
- Sliders
- Layout components -- group boxes, splitters, accordions
- Menus and toolbars
- Tables
- Trees
- Drag and drop
- Tool tips
- Context (right click) menus
- Async updates via Timers
Strengths
ZK's biggest strength is the jump in productivity that web developers are going to experience in switching over to the component GUI model, but it does have other advantages:
- As with any server-side widget framework that uses the bridge pattern, ZK decouples the rendering logic from the presentation logic. That means that they can retarget applications to devices other than the browser, such as desktop/swing or -- as Potix has announced -- a version for mobile devices.
- Timer component makes async update a breeze. You still have to pay attention that your server side logic doesn't run too long as "Events for the same desktop are processed sequentially. In other words, an event handler will block any following handlers."
- Doesn't try to reinvent the wheel. Makes use of existing Javascript frameworks, such as Prototype and Dojo. Eases integrating prototype-based Javascript widgets.
- ZUML makes it easy to build complex component trees. It also shortens the edit-compile-test cycle for developers.
- Allows developers to keep their business logic on the server side.
- Macro components -- components written in ZUML and composed from other components -- make it easy to build up more complex UI elements.
Weaknesses
There are some weaknesses as well, but most of them have more to do with platform maturity rather than design flaws:
- Documentation of both the Javascript engine and the method for writing new custom components is lacking.
- No IDE support.
- User interface state is stored in the client session. This can result in quite a bit of memory being used on the server-side, especially if lots of data and controls are combined.
- The lack of reference applications and tutorials make adopting best practices difficult.
- Look and feel is hard to control. At the very least, the details of how to change the standard "chrome" of windows, buttons, etc., needs to be documented.
- There appear to be some layout problems in some components, with slider controls floating outside of their expected positions. Could be stray positioning typos in the code.
Tomorrow we'll look at ZK from an architectural viewpoint and see how it holds up from a performance, reliability and scalability perspective.
Topics: Ajax Frameworks, Frameworks, ZK
Product Watch - Nusearch.com and Zohoshow
Two new AJAX flavored products launched today: Nusearch.com, a search engine with AJAX whizbang, and Zohoshow, the last piece in the Zoho Office Suite, a replacement for MS Office that includes Zohowriter.
As of this writing, it looks that Nusearch, with all it's AJAX innovations, has succumbed to the first day onslaught. I'll try and update this post when I manage to get through.
As for Zohoshow, it's basic, allows you to import existing Powerpoint files. Don't expect to do any charts or graphs or animations, though.
I've said before that presentations are just about the last thing for which I would want to depend on network connectivity. How many conference rooms have you been in that didn't give you access to the outside world?
Update 1: Nusearch came back up. Yes, there's some AJAX there, but in my opinion it's rather annoying. The search engine will let you preview their cached version of a page just by mousing over it's entry. It's so twitchy, though, because the table rows are close together. Also, the preview is really no better than a frame or iframe. Snooze. From a pure search perspective, it doesn't seem to do a very good job of sifting and ranking. The search results have a somewhat spammy feel to them.
I like dzone's little popup screenshot much better.
Topics: Ajax Examples, Ajax Products, Ajax Tools, Office, Rich Interactions, Search, Web 2.0
Wanted: A Javascript Source Code Search Engine
I use quite a few search engines in my day-to-day work. I expect you do too. There's one that I use quite a bit to see what's happening in the Open Source world. No, it's not Freshmeat. It's Koders.
Koders.com allows you to search the source code of thousands of Open Source projects. It allows you to filter by language (and license). That's really very handy when your looking for coding examples. It also let's you see when and where someone is using a particular Javascript library in their project. Looking for Dojo and Scriptaculous, it is no surprise that Webwork and Rails show up.
Now endless hours of fun can be had with the Koders search engine, but what I'd really like is a search engine that allows me to search all of the Javascript on the web. It's out there, it's readable, it's searchable. Surely google or Yahoo or whoever already slurps in the Javascript in their crawls. Why not add a new google engine for searching Javascript?
To anyone looking for examples of Javascript or AJAX, the utility of such a search engine is self evident. It might make corporate IT managers a little nervous to have all of their logic flapping in the breeze. Let that be a lesson to not put your business logic in the UI.
If anyone know of such a search engine or of any hacks or tricks to make existing search engines give up their secrets, please let me know. Passing xmlhttprequest filetype:js into google gives a less than satisfying result.
Update 1: Building such a search engine shouldn't be all that hard. The pieces are already out there. See the Heritrix web crawler that the Internet Archive uses for it's work.
Topics: Ajax Tools, Application Development, Best Practices, Search, Web 2.0, Web/Tech
Ajax Forms - Enhancing the user experience
The web is filling up quickly with examples of Ajax powered sites that allow us to do things we’ve never been able to do before on the web. From note taking apps, to spreadsheets, photo editors, and online games, Ajax apps like these are continually pushing the boundaries of what is possible, and in the process changing the way we work live and play on the internet.
However, we can also use Ajax to build better user experiences for the tasks we’ve already been performing on the web. One kind of task crying out for Ajax attention is form submittal, in which a user fills in a set of fields and presses the submit button.
Almost all forms today use the POST action in the SUBMIT button to upload data to the server, where processing gets done, and an entirely new page is sent back to the user. Depending on the results, this might be a “Thank You” message, or it could specify an error in the form submission (more likely when the form is lengthy). Either way, the experience is a poor one.
First, the navigational requirements are increased, as at least two pages are required-one for form and one for result. The result page usually contains no more that a couple of sentences displaying the results of the form submission, and possibly instructions on what next steps to take.
Second, the user has to wait until the end of the form submittal process to receive any error messaging. This increases the likelihood that there will be unnecessary typing and mouse movement/clicking, since incorrectly entered information into one input field may require a user to reenter fields down the entire form.
By using Ajax to asynchronously send the information to a server for processing, form entry and submission can be much more quick and painless.
Information can be uploaded processed and returned as the user enters data into an input field. Since not all the input needs to be sent at one time upon submit button on click, the user is told instantly, say, that the username he just entered is already taken.
Once all the required form data is submitted, the result can be displayed on the same page, allowing the user to move on to other, more enjoyable, tasks more quickly. If the form is small, and shares screen real estate with other content on one page, the user can continue on that page after the form is successfully submitted. No need to hit the back button.
Here is an example of what can be done to build a better Newsletter Signup form.
Ajax continually provides us with new and exciting web based products and services. But is also is a powerful tool for restructuring the way information is presented and manipulated on the web.
IDE Watch - GWT Plugin for IntelliJ
On Tuesday, Alex Tkachman over at Jetbrains announced that he had developed a plugin that adds support for Google Web Toolkit (GWT) to IntelliJ. As he says, it's only a "first prototype yet but it definitely gives an idea about direction we are targeting." There is more information and a watchable demo here.
I don't use IntelliJ myself, but from the demo it appears to perform a number of useful functions:
- It does all of the messy setup of the GWT Eclipse project and application creation for you.
- It allows you to create several GWT entities via menus: Module, Entry Point, Remote Service (client and server side classes), and Serializable classes.
- It allows you to edit Java and Javascript in the same editor window.
- It will detect use of undefined CSS styles in your Java code and allow you to automatically create it in the module's style sheet.
- It will both launch the GWT application runner and compile the Javascript for you.
All of this isn't exactly earth shattering, but it does take some of the tedium out of developing with GWT. The automatic creation of a Remote Service with it's three files (shades of EJB) is especially nice.
I didn't see anything in the demo about deployment, however. It would be nice if IntelliJ were to package the application up in a nice WAR file, ready to go. I've been tinkering with an Eclipse plugin for GWT. Mine just builds the application skelleton for you right now. Maybe I have to aim a little higher.
Topics: Ajax Frameworks, Ajax Tools, Frameworks, Google, GWT, IDE, Web/Tech
About Pathfinder
Recent
- Project Website Part 4: Drag and Drop in jQuery
- The App Store, iPhone, and You
- Multiple Column Sorting with Drag and Drop using Scriptaculous
- Five jQuery plugins that are a joy to use
- Visualizing Your Database Schema Entirely in Rails
- jQuery plugins: Five tips for separating the good from the bad and the ugly
- Resolved: Should schema.rb be included in your source control?
- Flash 10 - FileReference Runtime Access
- Papervision3d 2.0 (Great White) in Flex 3 (Part I)
- MetaWidget - Convention over Configuration UI
Archives
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
3d
Accessibility
actionscript
activerecord
Add new tag
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Frameworks
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Analysis
Android
Announcement
Announcements
antennae
Apollo
Application Architecture
Application Development
ASP.NET
Asynchronous Processing
awards
Back Button
Benchmarking
Best Practices
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
Chicago
CMS
COBOL
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CSS
Design
Design Patterns
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
Echo2
Echo3
Editorial
ERP
Ethnographic Research
Ext JS
Facebook
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player 10
Flex
flexunit
Flow
Frameworks
front end development
Games
Google
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
Gwittir
GWT
Healthcare
Hibernate
IDE
Ideation
IE
IE6
IE7
IE8
ILOG JRules
Information Architecture
Innovation
Instructional Design
Interaction Design
Interview
iPhone
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
Jobs
jQuery
JSF
JSON
JSR-94
Lazlo
Legacy Systems
LinkedIn
Mac
Mash Note
Mashups
MetaWidget
Methodology
Microformats
Microsoft
Mobile
Mootools
Mozilla
Music
MVC
Office
Open Screen
Open Source
Opera
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PHP
plugin
process
Web/Tech
Progressive Enhancement
Project Website
Prototype
Prototyping
QA
qooxdoo
Radiant CMS
rails
Really Simple History
Requirements
Requirements
Alice Toth
Requirements Visualization
RETE
Review
Rich Interactions
ruby
Ruby on Rails
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
SDLC
Search
Security
Selenium
Semantic web
SEO
Server Side
Silverlight
SOA
Social Networking
Software Processes
Songbird
Sprajax
Spreadsheets
Standards
Story Telling
Struts
Task Flows
Test Driven Development
Testing
Tools
Training
Trends
Tumblr
Tutorial
Tutorials
Unit Tests
Usability
Usability Testing
User Experience
user experience design
user interface
User Interface Standards
User Research
UXD
Video
Visualization
VLC
Volta
Web/Tech
Web 2.0
Web Design
Web Development
Webkit
Weblogs
Web Services
Web Standards
Widgets
will_paginate
Windows
Wireframes
WordPress
workflow
XML
XUL
Zeigarnik
Zeigarnik Effect