Application Watch - CShout

What is a shout box? An Ajax chat widget you can put on your site and have folks gab away. Voila! Instant community. I'm sure we'll make us of this new technology as responsibly as we've made use of everything else. ;-) CShout is just such a shout box, implemented in php. You don't need a database as it uses a simple text file as its persistent store.

cshout.jpg

I'll not make any judgements about the implementation. I do find this idea of easily making a page or a site into a community in this way a very interesting and compelling notion. We've been doing this for a long time, through comments, etc. But there's a fundamentally different quality to chat versus comments.


Technorati : ,

Application Watch - Valoony: Ajax Enabled Comparison Shopping

The German comparison shopping site Valoony has launched three new Ajax enabled comparison shopping mini apps: one for digital cameras, another for perfume, and -- my favorite -- one for wine.

valoony.jpg


The interface allows you to adjust various numerical parameters using sliders, select brands, types and specific stores, and enter search terms, etc., all of which cause the right hand content panel to update via XHR. On Joe Walker's 4 States of Ajax Adoption, I'd say this is state #2 -- Progressive Enhancement. The interface still uses IFrames and more traditional pre-Ajax techniques. Also, you can easily get into a confused application state by using the browser's back button instead of the "Zurueck" button in the page.

From a user experience perspective, I'm not sure this particular use of Ajax improves my shopping experience or is something that couldn't have been done before with Javascript and IFrames. Then again, I don't know what the old shopping experience was like, so this may be a vast improvement. It's certainly much better than my last frustrated fumblings on CNet. Also, I got an excellent deal on a 1996 Brunello. ;-)


Technorati : ,

Topics:

Web Serice and Mashup Pros and Cons and the First Google Clone

Over at Web Directions South, a good collection of pros and cons regarding web services and mashups from Kevin Yanks and Cameron Adams. Some choice things from the list

  • Having an API allows external programmers to access your data in a smart way. Page scraping is so Web 1.0
  • Programmableweb.com acts as an encyclopaedia of what APIs are available and what people are doing with them.
  • The amount of data mining capable through APIs is potentially frightening; especially if you're the paranoid type.
  • It's not all about maps - TagTV, Viral Video Chart, BlueOrganizer, Salesforce Adwords.
  • Cross Domain AJAX is a security risk that has come along for the ride. You can load images, CSS and JavaScript from other domains, but cannot load HTML or XML. JSON-P gets around this by disguising the new data as JavaScript. The potential problem here is that your data provider could very easily inject malicious script if they wanted to. JSON-P only supports GET requests and fails silently if you get the API URL wrong.

One thing I was not aware of was that a company down under -- ZoomIn -- is providing a google maps-like interface. I guess google maps for New Zealand and Australia leave something to be desired, leaving an opening to an upstart that looks a lot like google maps. You can include maps on your site, and the Javascript API looks just like the Google one.

zoomin.jpg

What does this all mean? It means that in Australia and New Zealand if you don't like google or it's terms of service, you can use an equivalent service with a minimal change. Is this the future of online services, or are we about to see a raft of API lawsuits? Hard to say.

 
  Technorati : , ,

More CMS and Ajax - What About CDS?

We talked about CMS and Ajax back in June, so I thought it was about time to see what had transpired in the world of CMS. Back then, it seemed that the CMS side (Content Management, i.e. the part your editors and authors use) had the most immediate promise for using Ajax, but that the CDS side (Content Display, i.e. the part that the actual readers see) was a different matter, with lots of headaches for managing scripts, style sheets and interactions. In essence, the domain model for most of these CMS's out there does not account for the fine-grained interactions of Ajax on the CDS side.

So, what are some of the more noteworthy developments for CMS and Ajax? All of the commercial vendors I've checked with, Interwoven, etc., have either added or are planning to add Ajax to their CMS apps, but not CDS so far. Beyond that, here are some highlights:

  1. MODx, a CMS and PHP application framework has been getting lots of press. The actual "Ajaxiness" of the app seems a little limited. And by their own admission, their focus is to introduce more of it into the CMS side, i.e. the "Manager" rather than the CDS. It does have "live search" and some Ajax powered voting, however.

    MODx is the first free PHP CMS to offer an API that fully supports Web 2.0 Ajax technology thanks to script.aculo.us. Expect to see this grow more and more into our manager over time, but you can make use of it today in your own custom applications including live search, web effects, Ajax communications and more.

  2. Micro CMS v.3.5 is a commercial CMS that also touts it's Ajax capabilities, again in the CMS side.
  3. Skeletonz is another CMS where the manager interface features AJAX and the CDS does not. This one is written in Python.
  4. MuraveyWeb, a Ruby on Rails CMS, seems to have closed up shop. The original files are still available on RubyForge.
  5. MooFlex CMS Demo - just a demo at this point. Not much more info than the Ajaxian article. I'd expect a little more Ajax in the actual demo from the Mad4Milk crowd.
  6. The Drupal CMS project has been busy adding Ajax to its CMS and CDS according to this levelheaded Ajax manifesto. They've settled on JQuery for their core Ajax library. They seem to be the most aggresive in adding real Ajax to the CDS, such as a real-time chat room. While we're on the topic of JQuery, check out the maiden issue of JQuery Magazine.
  7. Ajax Fly is a add in to the Mambo/Joomla Open Source CMS.

So far, I like the looks of Drupal and its Ajax CDS integration. Overall, people seem to be doing rather than thinking. I expect some folks are in stage two of Joe Walker's 4 stages of Ajax Adoption -- progressive enhancement -- while others are already in state three -- the second site. Stay tuned for more on what is likely to be a fast changing Ajax CDS landscape.


Technorati : ,

Topics: ,

Application Watch - Jotlet

OK, maybe there are too many Ajax calendars out there. Jotlet stands apart, in my opinion, in terms of it's usability and simplicity. With Ajax, there is the temptation to introduce too many whizbang behaviors, and this Calendar doesn't fall into that trap. The interface is simple and uncluttered.

Jotlet

It's missing some features, like exporting to Outlook, and I'm not necessarily recommending this calendar over Google, etc.. I'm offering it as an object lesson in how less is more in interfaces.

Topics:

Whither Canvas?

This world is but canvas to our imaginations. -- Henry David Thoreau

First support for the WhatWG canvas element was announced by Apple in Safari, then it was included in Opera and Firefox. A little while back, Emil did a cool hack with VML to produce a subset of functionality as canvas for IE. There was a rumor that google would release this or some other code as its Canvas for IE solution, and it sort of has, landing with a thud over at sourceforge with a Google Code imprimature.

There have been no apparent developments since then. It doesn't seem to have been widely tested, is much slower than canvas in Firefox, and has enough differences and functional gaps to make integrating it with Javascript libraries that build on the canvas tag somewhat difficult.

There don't appear to be any plans to support canvas in IE7, but things can change quickly over there, apparently. So, do you support canvas in IE with an impressive piece of late night hackery like Emil's work, or is support for canvas just not there yet -- a really nice feature not supported effectively for 90% of the web browsing public?

I'm leaning toward the latter. What do you think?



Technorati : , ,

Topics: , , , ,

Salaries Go Up for Ajax Jobs

This survey by IT JobsWatch shows that things are looking up for Javascript programmers. Over the last year, the average salary for Brit Ajax slingers has gone up 33% from £29,375 ($55,853) to £39,228 ($74,588). I'm sure these numbers are representative of trends in many other countries. Based on my own project experience over the last few years, the lowly Javascript programmer has gone from being a servant of the "design team" to a star, whose time is often more valuable than that of the programmers that make up the traditional "application team."

What's ahead for companies that are developing Ajax applications (and at this stage, that seem to be just about everyone)? There are those that will double down on traditional languages and skillsets via Javascript code generators such as GWT. But there will be enough companies going the pure Javascript route to drive up salaries even further. And behind the demand will come the training and certifications, the standards, tools and blessed frameworks, and the army of freshly minted Ajax programmers to fill all of those well compensated jobs. If you're considering selling all of your Java books and moving to a Javascript commune, do it quickly.



Technorati : , ,

Topics:

Javascript Library - JSGraphics

Sometime its nice to be able to deploy just a single web page without style sheets, plugins, what have you. Just a nice, self contained package. But what about the images? Surely you have to have external image? Well, no, actually. There's a Javascript library, JSGraphics, that has been around for quite some time that will allow you to describe and render and image using Javascript.

From the project page:

Color image is just a 2D array of colors. If you think about image this way you can see that it is possible to draw an image of the size N*M in HTML-only way - as a table with N columns and M rows, where each cell takes one pixel and has a background color assigned to it. Unfortunately even a small image represented like this in HTML results in a large and complex code for the browser. But for artifitial images it is very easy to use RLE compression - if there are several cells in a line of the same color you can replace them by one cell with the correct colspan/rowspan attributes assigned for it.

There are three cool things about this type of images:

  1. They can be posted on the pages where images are not allowed (like some forums, or livejournal),
  2. The size of HTML sended from the web server to client's computer is not very large - the HTML for the images is generated on the client's computer only,
  3. They can be animated to react on user input.

I made a simple JavaScript library that allows you to use simple 2D graphics functions to create such images (like drawing lines, points or circles). Comments and suggestions are welcome.

The GCanvas class provides all the usual operations -- drawing lines, elipses, filling areas -- and subclasses of the GOutput class allow for different kinds of rendering, such as DHTML and Java Applet. You can even do animation with it (see the eyes demo). Great browser compatibility, for when you can't rely on SVG in the browser.



Technorati : , ,

6 Tips for Designing Mobile Interfaces

I recently had the pleasure of working on a user interface for a mobile application.  Our client is migrating their existing software product from use on the desktop to a handheld device.  I am part of a team that is designing the GUI. 
Although many of the issues involved in designing handheld and desktop GUIs and are similar, handheld devices present unique challenges to interface designers.  Here are 6 tips that can help you ease your way into designing mobile interfaces…

1 – Know the device’s screen resolution.
It’s obvious, but the most important issue is being aware of the resolution you are working with.  Many handheld devices such as PDAs use QVGA (320 x 240).  Mobile phone displays can go much smaller.  This will have an effect on the amount of text and imagery you should design into each screen. 

2 – Experience the physical device. 
It’s crucial to understand how users will interact with the device before you can design for it.  Pick up the device and use it, note how you naturally connect with it.  What finger are you using to press buttons?   Is the device light or heavy/large or small?  How does this affect your hand movements?   All of these will have implications for the interface design.

3 – Know the display’s color depth.
Although you’ll probably be designing using at least 24 bits of color (16.7 million colors), mobile devices typically have much lower color depth.  The one we were working on can only display 16 bits of color (about 65 thousand colors).  65 thousand colors are more than enough to work with, but you should be aware of the differences.

4 – Understand the limitations of the device’s software.
Handheld device software is generally at least a few years behind its desktop and laptop counterparts.  Make sure you’re designing something that can be coded in the device.

5 – Understand the implications of the touch screen. 
Almost all advanced mobile devices feature touch screens.  Become familiar with the device’s touch screen before you design. Be aware of things like touch sensitivity, and hot spot preciseness.  They will impact the user’s interaction with the device. 

6 – Be aware of the device’s audio capabilities.
Many devices come equipped with a set of sounds that can be triggered by user interaction.  Audio can be very helpful in providing feedback to the user when he or she is not concentrating on the device itself (such as when performing a repetitive task, or a task that requires one to look elsewhere).

Topics:

Flow in Applications

In his long-range studies, Mihaly Csikszentmihalyi has described the condition of "optimal human experience" as "being in the flow," a state in which a person is fully engaged and in control of an activity. Although Csikszentmihalyi never specifically applied the concept of flow to user experience, several practitioners have enthusiastically bridged this gap, among them Benjamin B. Bederson and Andrew B. King.

However, much of the work on flow in HCI has been concentrated on the web experience. As a matter of fact, Csikszentmihalyi's concepts are even more relevant to the design of applications. King notes nine dimensions discerned by people who have experienced flow:

  • Clear goals
  • Unambiguous and immediate feedback
  • Skills that just match challenges
  • Merging of action and awareness
  • Centering of attention on a limited stimulus field
  • A sense of potential control
  • A loss of self-consciousness
  • An altered state of time
  • An autotelic experience

It is not at all difficult to correlate most of these nine end results with the standard list of usability heuristic goals. Flow, then, is a desirable design goal, especially for applications and other task-based systems, as researchers Hoffman and Novak note:

"Less experienced users tend to see the web in a hedonic, playful way, while more experienced users tend to view the web in a utilitarian way, or a means to accomplish a task. The authors found that telepresence/time distortion, exploratory behavior, focused attention, and challenge/arousal correlated with recreational web use, while skill/control, importance, and experience correlated with task-oriented activities, such as research, work, and shopping."

As application designers, we are of course concerned with user workflows and system taskflows:  we need also concern ourselves with the aspect of "flow" that occurs within the users themselves.

Bookmarklets 101

Today I want to build the "Hello World!" of bookmarklets. Actually, I'm going to build two versions, the second of which will allow us to do bigger and better things than the first. So, what exactly is a bookmarklet? It's a bookmark that points to javascript instead of a web page -- javascript:... instead of http:.... This Javascript then runs in the context of the current page -- sort of a Greasemonkey script that you invoke by clicking or selecting a bookmark.

If you're using Firefox, this is going to be a whole lot easier than if you're using IE, Opera or Safari. In Firefox, you can drag a link to your toolbar and have it easily available for use. In IE and Opera, you can bookmark the Javascript link and have it available in your bookmarks dropdown menu. As far as Safari goes, not all bookmarklets work in it -- as we'll find out, there's not really enough space in a bookmarklet to do much cross browser support --, but this won't really be a problem for us given this bookmarklet's code and the direction we are going with the second version.

OK, here's the first version. It's about a simple as it gets:

javascript:alert("Title: " + document.title);

You can try out this bookmarklet below.

Drag the following link to your toolbar or bookmark it:
Title

IE will complain (provided your system has the latest security patches) about adding an unsafe bookmark. Browse to a different page and select the bookmarklet and you will see that it correctly displays the page's title. So far so good.

What if we want to do something more substantial, say write a bookmarklet that would inspect the DOM of a page and modify it based on some sort of algorithm? Well, bookmarklets can only be so large -- no more than 255 characters in some older browsers, a few thousand characters in the case of the newer ones. If you're going to write bookmarklets that do interesting things, where are you going to put the code? One approach, is to use an Ajax technique known as DOM-based on-demand Javascript. That's just a fancy name for inserting a script element into the DOM of the current page. There are lots of bells and whistles we will add in future examples, but for the moment we will keep it simple.

The second version looks like this:

javascript:(function(){var s,d=document,a=function(o){d.body.appendChild(o)};s=d.createElement('script');s.type='text/javascript';s.src='http://labs.pathf.com/bm101/hello.js';a(s)})();

At the top level we are declaring an anonymous function and calling it, all in one step -- (function() { .....})();. The code creates a script element, sets its type and source and appends it to the document. We've used lots of dereferencing to save characters, such as assigning d=document. Now, on the server-side, we create a little JavaScript file that contains our familiar alert statement:

alert("Title: " + document.title);

Try out our new example:

Drag the following link to your toolbar or bookmark it:
Title2

OK, so what's the big deal? Didn't we just do the exact same thing in a more complicated way? Yes and no. Yes, the new bookmarklet does exactly what the old bookmarklet did but in a different way. It included a JavaScript file into the context of the current page. Into that file we could have put as much other JavaScript as our hearts desired. We could even, with some precautions, have included our favorite Ajax library to manipulate the DOM and make asynchronous requests. The bookmarklet thus becomes just the leading wedge that allows us to load in more substantial program logic.

For a Web 2.0 example of a bookmarklet, have a look at Blummy, which allows you to share useful bookmarklets with other users. A word of warning, however, about bookmarklets: you're inviting someone else's code into your browser. Once in, they can do a great deal of mischief. When evaluating bookmarklets ask yourself, "how much do I trust this company or individual?"

Next time we'll go beyond the mere "Hello World!" and try to be a little bit more disruptive.

 
  Technorati : ,

Topics: ,

The Effects of Unbreaking IE

I was listening to Audible Ajax Episode 18 -- the interview with the IE7 team -- yesterday, and about halfway into the podcast, I heard something that had me fall out of my chair with laughter. One of the guys (sorry, they all look alike on a podcast) mentioned that if you surf the web for a prolonged period of time with IE7, you begin to see little anomalies in presentation, functionality, etc. If you dig a little deeper, you see that people are depending on IE6 quirks and bugs to get their sites to render and perform correctly. Aside from the hillarity of everyone having to unquirk their sites and applications when IE7 comes out in general release, it is an object lesson in how Microsoft can embrace and extend a set of standards even if they don't mean to.

Hopefully the IE releases will be coming faster now, and bugs won't have a chance to be enshrined as standards anymore.



Technorati : , ,

Topics: ,

Widget Watch - BeanView - Forms and Validation for Echo2

Echo2 has been described as Swing for Ajax, and its component model does have a passing similarity with the Java desktop GUI. So it's not surprising to see a component come out for both Echo2 and Swing at the same time: BeanView 1.1, which was released yesterday. What is BeanView?

BeanView is a Java library - a system for seamlessly rendering a JavaBean to a form and back.

In technical terms, it relies on the information obtained from reflection of the JavaBean to generate forms and update the beans from these forms - so, if you create a JavaBean with a method get/setFirstName(String in), BeanView will automatically generate the form with a textfield to enter a "First Name". Supported features include:

  • Per visual widget error reporting
  • Support for validation (both a variety of built-in validation types and an easy customization system)
  • Support for a wide range of built-in data types
  • Support for complex data models, such a mapping a collection to multiple selection list box
  • Automatic configuration based on JavaBean meta-data (for example, if a JavaBean declares a get/setFoo(int input) method, will by default generate a text field with integer validation.

Invalid form data is indicated by a big red exclamation mark and a popup tooltip. Below you can see the Swing and Echo2 versions side-by-side.

beanview.jpg

The latest release of Echo2 also allows you to explicitly set the render id's used to identify components, i.e. the DOM id attribute. This means you can test your BeanView forms with an automated test tool like Selenium.


Technorati : , , ,

Topics: ,

Framework Watch - ThinWire

Since I'm such a big fan of server-side Ajax frameworks, some readers have been encouraging me to take a look at ThinWire, a Java-based component GUI framework. On the surface, this framework promises the same things as Echo2 and ZK -- a familiar GUI development model, increased productivity plus lower complexity than traditional web applications using Ajax, and a single development language and environment.

Also on the surface, the demo applications show off an attractive set of widgets, like for the Mail application below. I do have a few minor complaints, such as a particular panel blanking out while I was dragging a dialog box. If this behavior was intentional, it certainly was inexplicable. They are missing some of the cooler behaviors that Echo2 and ZK already support, such as drag-and-drop, and leveraging other Ajax and JavaScript code seems to be at an embryonic state. They are working on an implementation of drag-and-drop for the next major milestone.

thinw.jpg

Under the covers, the ThinWire appears to be divided in the usual two pieces of the server-side framework: a client-side JavaScript engine, and a Swing-like Java component GUI toolkit that sits on the server. Documentation looks to be a bit sparse, although there is a nice tutorial by a third party here. Again, they are working on completing the API documentation, and I'm sure friendlier and more copious documentation is on the way.

The company distributes the framework under both a GPL and a commercial license. I guess the latter is where they make their money.

Overall, the framework looks promising, but less mature than Echo2 and ZK; when developing, some assembly of the project structure is required. If they had released it six or 12 months earlier, they might have built a bigger developer following. As it is, adoption looks somewhat weak, and they trail in the wake of the other server-side frameworks.

 
  Technorati : , , , ,

Topics:

More Javascript Code Generators and Another Ajax OS

So, I missed two Javascript code generators, found the new home of a third, and found one more Ajax OS beastie. First the code generators:

  • ParenScript has a new home. This is the Lisp->Javascript code generator. An example:
    (js
    (defun foobar (a b)
    (return (+ a b))))
    

    and the Javascript:

    function foobar(a, b) {
    return a + b;
    }
    
  • ST2JS - A smalltalk to Javascript translator. Not a project overflowing with documentation and friendly explanations.
  • jsc - this is another C# (or ) to Javascript code generator.

    The compiler extracts CIL from a .net assembly. It filters out the classes which are marked with the ScriptAttribute. It selects the target language and emits the source.

    I've already blogged about this tool once before, but it does belong in any listing of Javascript code generators, so in it goes.

Next, on the heels of our entry on Atomic OS, we have another cute little command line shell toy in Ajax: JS/UIX Terminal.


jsuix.jpg

It's cute to be able to play invaders in the browser, for about 5 minutes. Under the covers, it purports to be an OS written in Javascript, implemented on top of the browser:

JS/UIX is an UN*X-like OS for standard web-browsers, written entirely in JavaScript (no plug-ins used). It comprises a virtual machine, shell, virtual file-system, process-management, and brings its own terminal with screen- and keyboard-mapping.

Cute as well, and probably an interesting learning experience. Not sure if the OS on top of the Browser is where the future of Ajax is. Abstracting services down to that level seems like overkill.


Technorati : , , , , ,

About Pathfinder

Follow the Blog

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email

      

    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com