Saturday, October 25, 2008

When I grow up ...

When I grow up, I want to be ... a devsigner. No, seriously: developer + designer, geddit? OK, so the word itself is in dire need of a makeover, but the concept is sound. I'd not heard the term before, but it was being used a fair bit at AjaxWorld last week. The stereotypes are that developers cut code, worry about elegant architectures and test strategies and get high on recursive data structures. Designers create images, worry about visually effective presentation and aesthetics, and get high on perfectly balanced font faces. More importantly, so the stereotypes say, the designers create a thing of elegance and beauty, and the developers mess it up when they turn it into working code. A particularly irritating example of this is Alan Cooper's book About Face 2.0, which, while it also contains lots of good advice on interaction design, carries a refrain that designers will listen to users and craft a thing of ease and beauty, and are then forced to dress it in virginal white and chain it to a rock near the caves where the programmers live. OK, so I may exaggerate slightly, but he says, for example:

It simply isn't possible for a programmer to advocate for the user, the business, and the technology at the same time.

I accept that some – many – developers simply aren't interested in UI issues, and that being a user advocate and being a developer are different skillsets. But I don't accept that it's impossible for one person to have both skillsets. Enter the devsigner, and apparently we need more of them. I agree.

Actually, I first learned about user centred design some 15 years ago or so. We used it to great effect on a project I was working on in Delaware. We had the whole team participate in the user-study and requirements capture phase, and while I guess different people got more or less into the process, I think everyone gained from it. Personally, I loved the whole process.

User-centered design is, to me, the heart of being a devsigner. Whether it's a developer acquiring design skills, or a designer learning some coding skills, a passionate interest in "what's the user perspective in this artefact?" is the key.

If you're interested in the general world of design, I recommend the core77 blog.

del.icio.us: design, opinion, software-development

AjaxWorld wrap-up

Back home now after AjaxWorld, with the jet-lag beginning to fade. It was, on the whole a good event, though not quite what I expected. For starters, it was smaller than I anticipated: fewer delegates, fewer talks and a smaller trade show. I was basing this on Semantic Technologies, a conference held in the same venue. I expected that SemTech would be a more niche interest, but the last time I was there (2008), it was significantly bigger than AjaxWorld turned out to be. The explanation may be the economy, or the fact that there's another AjaxWorld on the east coast USA earlier in the year. Still, I found plenty of people to talk to in the breaks, and some very interesting talks.

On the plus side, I did get a pretty good overview of the state of the art in rich internet applications (RIA). We're not doing much RIA work in our project at the moment, but anticipate doing so soon. Now is a good time to get a general feel for the options, in anticipation of making some technology choices for the UI part of the project in the near future. I found that there are more Javascript libraries/frameworks than I thought, even though I already knew of quite a few. There are also more choices for approaching pure-Ajax (as opposed to other RIA) UI's without directly programming JavaScript: I already knew about GWT, of course, but for example IceFaces lets you render your UI into a DOM on the server-side, then has clever ways of echoing the server-side DOM to the client. Neat. Taking another tack, Appcelerator lets you build on a message (aka event) oriented architecture familiar to Swing developers, but lets you pass events to and from the server, as well as within the client. There were plenty of other cool demos on the trade show too.

On the downside, I was hoping for a bit more analysis. It seems to me that a taking a RIA or rich client approach can bring some pretty significant architectural challenges. How much data should be cached in the client? How to ensure security if the client is outside the corporate firewall? How about architectures for running disconnected? I know about Gears and Air, but how to really exploit those platforms effectively? What are the anti-patterns to avoid, and the good patterns to adopt? There were fragments of this (and there was a self-contained Ajax security bootcamp on day one that I didn't attend), but I'd have liked more. There was a bit more analysis on the split between development and design, but I think there's more to play out in this conversation (see separate post).

Double downside: too many of the talks were basically extended product adverts. "See, here's a feature of our product. And another. And another." Yawn. I'm cool with people using their own personal or professional experiences – actually, they make for better narratives than empty marketese or dry theory. But there's a line. The better talks made some general points about the industry, trends, architectures, whatever. The big name keynotes (especially Microsoft and Adobe) handled this gracefully while still getting their own "Look! Shiny!" points across.

The conference hotel was nice, but expensive. I didn't think so at first because the basic room rate isn't too bad for large US hotels, but the meals were expensive and parking is US$26 a day. Tip: if you stay at the Fairmont, join the loyalty programme. Free to join, and immediately saves you (or your budget holder) US$16.99 a day in in-room internet charges.

All said and done, I think I'm going to recommend to my boss that we do our RIA prototyping in Flex. I'm not 100% sure what the right option is, long term. Indeed, it probably depends a lot on context (consumer vs. enterprise, for example). But I liked Adobe's story on the ubiquity and consistency of the Flash engine, Flex itself looks like a nice environment to work in, and I heard enough speakers at the conference to validate that view. If we worked in a .Net environment, then Silverlight would be an obvious choice, but our back-end code is all in Java. Flex plays nice with RESTful web services too, so putting a Flex front-end on my Ruby code won't be a problem.

del.icio.us: ajaxworld, notes, ria.

Thursday, October 23, 2008

Idea: inverse CAPTCHA

Apparently, increasingly sophisticated AI programs are now able to crack CAPTCHAS fairly reliably. The response from CAPTCHA owners has been to make the images harder to crack. While at AjaxWorld I've just posted a bunch of entries to this blog. I estimate my error rate to be more than 50% – more than one time in two I failed the test of being a human (according to Google, we bow before them). While the occasional post did go straight through, it sometimes took me three or four attempts to correctly parse the images Google were throwing at me. I see a time coming when CAPTCHA decoding programs will be more effective than humans at decoding the wretched things. So here's my idea: we can't just reverse the equation (decode CAPTCHA = machine, fail = human) because that would be too easy to game. But I don't imagine that it would be that hard to classify the types of error that real humans make, and screen unusually accurate attempts as non-human.

Yes, irony, but not entirely.

Wednesday, October 22, 2008

AjaxWorld session: Michael Oliver

Flex, Flash and Loosely Coupled On Demand

CTO, Corent Technologies

Build metamodel of the application using a GUI tool, then can generate rendering of the metamodel as Flash, Flex, AIR, portlet, Google gadget, ... long list. Interesting to a point, but the talk was basically just a product pitch.

del.icio.us: ajaxworld, ria, conference, notes.

AjaxWorld session: Elaine Wherry

Scaling the Synchronous Web

Meebo: online instant messaging. Scaling challenges: after one year went from 3 users to 65 million (?users or page hits, unclear) daily over course of one year. Has to be snappy, real-time and accurate.

Comet protocol: overlay handshake over http. Can only have two XHR connections open at once.

Site is one page only, typical user session is two hours. Have to be very careful about page errors.

Approaches to scaling problems: simpler is better, know your bottlenecks, quick fix or home run, use better abstractions.

Keeping simple: released on day 1 with very few features. Added features in response to user feedback. build quickly and inexpensively as possible. Keep your worry list small: only solve the problems you actually have. Save time for other ideas in case this doesn't work out. Used one gaim process for each user (simpler). Makes problem identification easier.

Cowboy scaling: shoot from the hip. Better: make smallest possible change that has the biggest effect. Use as data/tools driven approach as possible.

Know your bottlenecks - monitoring good, but don't overdo

quick fix or homerun? need some quick fixes to buy time (e.g. kill -9 pid). Add more boxes. Look at risk/reward ratio. Need either a quick fix, or a complete solution that has a big impact. Avoid anything in the middle. Move from apache to lighttpd gave a 3x improvement = quick fix. Homerun was to remove the CGI and build a server plugin module (mod_beebo).

Refactored core architecture when iPhone launched. Added new abstractions. This enabled new products, e.g. FireFox extension.

200 million messages per day. 54K kiss emoticons per day. 35 million unique views per month.

del.icio.us: ajaxworld, ria, conference, notes.

AjaxWorld session: Laurie Gray

User Experience and RIAs: How Does It All Come Together?

Senior user-experience architect for OneSpring

Currently using iRise for UI simulation, but would like a tool that can generate a skeleton that can go to the dev team.

Those who cannot learn from history are doomed to repeat it.

How we got here. Taylorism (1912). WW1 - fit people to jobs based on simple criteria (e.g. size). 1930's military simulations. WWII - shift in thinking: make the technology work for anyone. Postwar: growth of electronics industry; start to think of system design; birth of human factors; shift in team practices. 1965-present PC mentality, no longer have to be a specialist to access technology. Then the web happened.

Goal: interface should not distract the user from their task. Transparent interface (q.v. Steve Krug's book). Secret: observe users carefully, understand how people think.

Things are changing: visually moving transactional GUI's are forcing us to rethink web conventions, controls, etc. But: are the users keeping up with this change? Neilsen 2000 article (Flash 99% bad) - encourages design abuse, breaks web fundamentals, distraction, accessibility. Same critiques can apply to dynamic web applications.

Devsigner – developers learning to think like designers. But devs don't need to be "Designers" just have to learn to design the right things well. Creating a roadmap important: get consensus on what the main goal of the project is. Focus on the problem that is being solved. Decide how you will know when you are done, who will decide when it's done, decide what you're not covering.

Keep the user squarely in your sights. Use personas. Innovation for its own sake isn't always good.

Have a plan.

Don't make your users relearn everything. Don't lose sight of the fact that for many users, computers are too complex.

Consistency. Intra-site consistency, but also consistency with existing html controls. Make search boxes look like search boxes, rather than have to label them so that users can figure it out.

Create and use patterns. Use standards, both internal to your organization and external. Make the dev's job easier.

Ask your users: standard options, plus suggestion: create a user advisory board. Users who are willing to give feedback on site over time, in return for e.g. free membership.

Presentation and example documents are available. Includes reading list.

del.icio.us: ajaxworld, ria, conference, notes.

AjaxWorld session: Greg Murray

BluePrints for AJAX Applications

Project lead for jMaki

Conventional web: server manages entire view, lots of xml, browser is dumb terminal. From 2005, ajax appeared. Challenges we face today: multiple scripting languages, service-driven widgets, controlling access to services, security risks, performance.

The blueprint

  • modern MVC design
  • RESTful JSON services
  • json for data exchange
  • rendering library

On the client: use true JSON (Crockford) json.js; use pub-sub bus for inter-component comms; verify all inputs on the client (use a script to avoid injection attacks); don't take script from strangers (maybe malicioius, more likely may have their own security holes); avoid browser detection; use namespaces.

On the server: use a light RESTful architecture; keep session state to minimum; manage access to services (use API keys); use server to access and convert to JSON/JSONP/XML; set correct headers

Consider a library for generating correct JSON more easily. json.org Java, or G-JSON (?).

Choosing library - overview of various choices. They all have advantages.

Frameworks. jMaki premise: integrate your javascript with existing libraries.

The presentation jumped about a bit. I'm not quite sure what the presenter's take-home message was supposed to be. I'll probably spend some time looking at jMaki later though.

AjaxWorld session: Rob Tweed

Design-based Web Application Development: The Essential New Paradigm

Central thesis: designers can't program, programmers can't do design. When programmers drive the project, design suffers and project goes off the rails. Instead, if we simply and standardize the plumbing by imposing a rather rigid model of fragments with get/update verbs then designers stay in control and everything works.

The speaker did not present any particular evidence for this view, and it struck me that while it might work for some basically straightforward projects, real innovation requires a more sophisticated model. Simply inverting the pattern to say that the designers are in charge and must serve the programmers is as implausible as saying the reverse. In my view, both design and development are important in creating an innovative new capability, and it's up to the project director role to ensure that both are equally well able to contribute. Put another way, any application that is well enough understood that either design or programming can be commoditised (in the way that this approach commoditises the developer role) is too far from the boundary to be interesting. The good stuff happens at the edges.

del.icio.us: ajaxworld, ria, conference, notes.

Tuesday, October 21, 2008

AjaxWorld session: Mark Meeker

Coding the UI: Lessons from ebookers and Orbitz

Experiences from re-engineering of Ebookers.com and Orbitz.com. Change rate: 1971 changes to one particular CSS file in svn. Team of 20 developers; fast moving site. Have to keep up with changes in browsers, etc. Ebookers Europe – 22 different localizations.

Old site: large amounts of JavaScript, 560 files with html tag. Record: 66 tables on one page (with no tabulator data). Redesign goals: i18n, universality, maintain high quality code, re-use, consistent user experience.

I18n: differences in times, dates, distances. 3000+ text items that need localization. Even when English is on the site, there are still differences in choice of words. Small words can expand up to 500% in some languages. Rule of thumb: allow for 40% growth from English. Watch for text wrapping issues – affects the page design. E.g: put labels above edit controls, not to the side.

Universality: want to not care about OS, browser or device. Following web standards really paid off. POSH (plain old semantic html). Use reset stylesheets to smooth some diffs between browsers. Validate CSS on check-in.

Progressive content: content is key. Get semantic HTML working. Then use CSS and/or JavaScript to improve appearance. Graded browser support: not everyone gets the same experience, not all or nothing. A-grade: white list, tested by QA; C-grade: blacklist; X-grade: everything else, wait for complaints before fixing.

Quality: automated testing. Static analysis. Constraints on code: e.g. ban some constructs, require some others (e.g. labels on all input fields). Logging: use blackbird JS. (www.gscottolson.com). Separate developer convenience – file structure, comments, etc, from deployment issues (repackage the files, strip the comments).

Modularity: standardised templating/module system. Avoid using ID's in CSS.

Consistent experience. Keep no of. interaction patterns to a minimum. Use the ones that work best everywhere. Lightbox to factor out common dialogs. Consistent error message placement. Review site and introduce a pattern library. Build shared controls for common patterns.

Slides: available.

del.icio.us: ajaxworld, ria, conference, notes.

AjaxWorld session: Steve Maryka & Ryan Moquin

General session by ICEsoft: How Can AJAX Improve Homeland Security?

Instant communications for first responders. Demo/application built with British Aerospace.

IceFaces: open-source, standards based. Ajax platform in pure Java (no need to write JavaScript). Extends JSF. 50K registered developers. Deploy to any app server, combine with leading Java frameworks. Key innovation: direct-to-DOM rendering. Presentation code is rendered to DOM on the server-side, then sync'ed through client-side JavaScript library to the client. Uses a push mechanism to route state changes from server to client without waiting for a user interaction on the client.

Portals add complexity. Browser-imposed connection limits (IE limits connections to two). Their framework adds client-side connection sharing, and similarly need server-side connection sharing. Hide this complexity from app developers.

conclusions: the asynchronous web will be everywhere; foster developer creativity, not focus on low-level Javascript plumbing.

AjaxWorld session: Eric Farrar

It's 11pm: do you know where your queries are?

RIA platforms often wrap underlying database in some abstractions. Object-relational mapping. Hide database complexity.

Inherent difficulties: database normalization is a different pattern than the way we build object collections. DB's only store scalars. [one other - missed it].

ActiveRecord pattern: the meat of an ORM that handles CRUD operations. Treat regular objects as persistent objects. Ideally abstracts all database interaction.

Trade-offs (no right answers). Advantages include: easy to learn, simplicity, database agnostic. Disadvantages: performance (can be 50% slower); lowest common denominator; concurrency support is harder. Rest of talk is about how to ameliorate some of these issues.

Managing indexes. Ensure an index is present on anything you will search for. Avoid table scans. Performance problem may not appear in development, since table scans are tractable in small db's. Can't just index everything: takes space, slows down updates.

Lazy loading: often don't need all of the data. Danger in getting a whole object at a time: might pull in more than required. Must be possible to selectively (lazily) load: e.g. in Ruby ACtiveRecord :select => ["name"].

Client-side joins: can issue lots of individual queries rather than one join query on the server. In Ruby ActiveRecord :include => [:office]. Eager loading pattern.

Summary: be aware of what the underlying database is doing with your ORM models. Which seems plausible enough, though I'm not quite sure why this talk was at an RIA conference. I was hoping to hear some comments on the difficulties of managing queries when the app code is running on the client side in potentially a much restricted computational environment (and also outside the firewall).

del.icio.us: ajaxworld, ria, conference, notes.

AjaxWorld keynote: Charles Kendrick

Beyond widgets: what a RIA platform should offer

RIA for business should offer specific capabilities for end users: richness is not an end in itself. Aim to cover the traits that enterprise apps should exhibit.

Smartclient product

Data agnostic data binding. Data abstraction – data source – provides four basic CRUD actions. Avoid controller classes, use SQL-like protocol. Can mock data-sources in early development, switch to production data later.

On the fly (client side) filtering: nice, but does not work with production data loads. Often smart filtering gets turned off. With SmartClient: can dynamically switch between performing operations on client or server; knows whether it has a complete cache of the result set. Reduces the number of requests that the server has to handle.

Cross-browser support. Not either/or, but a continuum. Smartclient tries to be fully capable of insulating the RIA from all browser quirks.

Debugging support is important. Should debug application, not just JavaScript. E.g: why is a component in the wrong place or at the wrong size? Complement to FireBug.

Schema driven components. Grid uses schema to configure columns, whereas form uses the schema to drive the fields. Schema shares metadata across widgets. Can import metadata from SQL, XML schema, object model. [No mention of RDF/OWL -ijd]

Data relation awareness. Declare a foreign key relationship between datatypes. Widget can use that to drive behaviour.

Summary: rather an extended product pitch than a general talk, but interesting capability. Free version of platform is LGPL.

del.icio.us: ajaxworld, ria, conference, notes.

AjaxWorld keynote: Kevin Lynch

Kevin Lynch - CTO Adobe

How to move the new generation of computing forward. Four areas: better tooling, .... (rats, I wasn't quick enough)

Better tooling. Dreamweaver support for adding arbitrary Ajax components directly in visual view in Dreamweaver. Consistent support for open source. Flash definition is open and unencumbered.

Better frameworks. Flex free and open-source. Same run-time across all platforms. Flexbuilder can turn on source enabled version, enables view source in deployed apps. Good for helping others to learn from examples.

flash content indexing at search engines. Project Ichabod: headless flash player deployed at web crawl sites. Can the available text in an application, and click on the buttons, etc. But how to get the user back to an inner page. How to index the state of the application? Something we (framework companies, developers, customers, etc) need to work together on. Good practice: update the state identifier by changing the address bar in the browser.

Advanced browser capabilities. HTML 5. Flash plays most of the video on the web. HTML 5 video tag can play video on page via flash. Can be controlled via javascript on the page. Open-source release, available in "a few weeks". Flex adds programming power to Flash. Global framework cache - caches the Flex app, but can be used for other frameworks. Flex databinding: binary sockets (roll your own protocol), bi-directional messaging, clipboard access, local storage.

Increasing web clients, too much diversity. Flash player widely deployed (Flash 9 deployed over 80% of clients within 9 months). Provides a more consistent platform.

New features in Flash 10: 3D engine; dynamically generated effects; with user's permission, can access camera and save to local disk. 10 million installs per day. new scriptable music and audio effects. Nice example of scriptable image editing effects. Text handling in flash 10 much improved, including full i18n support. Aiming to bring flash player 10 to mobile platforms

Web apps in new contexts. Air: run web apps on the desktop, can do things that browsers can't do. Aiming for 100 million Air installs this year. Blackbook example code – sample context manager showing off visual effects to enhance the UI. Same runtime works on Win, Mac and Linux.

Desktops and devices. More mobile phones are connected to the web than PC's. Emerging markets: 1 billion people will use the Internet via mobile phones without touching a PC. Can take applications that run on pc and play on mobile platform. We need to start designing for small screens as well as large screen, maybe even start with small screen constraints first. Apps will run on many screens, possibly simultaneously. Demo of same music app on PC, Nokia and Wii.

Edit: it's Kevin Lynch, not Ken. Sorry Kevin.

del.icio.us: ajaxworld, ria, conference, notes.

AjaxWorld: Michael Galpin

The networked application pattern: an emerging RIA design pattern

blog.

Traditional web application: sends a request, application server does a bunch of stuff, server returns HTML. Bad.

Networked application = good. Make a request to a web server or CDN. static content. Sends back an application - code - to run in the browser. App uses various frameworks, but code runs on client. Now app makes request to app server, server sends back data.

Why? one reason: architecture. 1998 - hello world, presentation and app on server. 2003: ajax presentation spread between server and client. 2006: RIA - presentation on client only. Another reason: performance. non-varying content can be cached at the network edge. Saves money (cpu power, less bandwidth used). Mobility - app can be rehosted on other servers, or on the desktop (Air).

What about Ajax? send request, get html+js, use framework on client, send xhr, get back ?x. If ?x is html, can be complex. May need additional javascript, css, etc. If ?x is data only, we end up duplicating the presentation code between the app server and the client-side JS. "Ajax is hack"

Solution: JS widget kits, e.g. dojo, extend js, jquery, etc? Given a better abstraction for making changes on the client. Good points: functional language (JS inspired by scheme); frameworks (make JS object-oriented); lots of choices. Bad: browsers (cross-browser inconsistencies, many browsers); DOM APIs; mix-n-match (can we mix, say, extend and jQuery without name collisions). Ugly: javascript is really slow; cross-domains (no good solution for secure cross-site scripting); ref count garbage collection (can get reference cycles which block gc).

Solution: GWT? Write in Java, compile into javascript, abstraction for Ajax calls. Good: supports OOP; static typing; produces killer Javascript; tool support (e.g. Java debuggers). Bad: supports OOP (it's not for everyone); static typing (duck typing more flexible); killer Javascript (easy to debug when it's Java code, hard to debug when translated to Javascript). Ugly: it's still Javascript (see above)

Solution: Flex? Good: MXML (declarative); ActionScript (ECMAScript, OO, inheritance); Flash engine good for graphics; tool support; browser independence; fast evolving (75% penetration of new Flash player version in six months); good for polished UI's; support for developer/designer collaboration workflow; speed (static typing allows better optimisation); better GC; support for cross-domain scripting using declarative policy file (crossdomain.xml). Bad: licence costs; hard to find experienced developers.

Also consider MS Silverlight. MS looked at Flex, kept the best bits and fixed the obvious problems. JavaFX – good for 3d API's. Both Silverlight and JavaFX have questions over deployment/penetration.

Acronyms: SOUI (service-oriented UI), SOFEA (service oriented front-end architecture)

Question (by me): "doesn't DOM-manipulation a la Ajax integrate better with the browser model (bookmarks, history, copy-paste, etc)? Answer: not really. Flex has lots of API support for browswer integration [I didn't manage to note down the long list of things it can do]. All RIA's have some difficulty with the history model of page-based browsing, though there are workarounds.

Summary: entertaining speaker with a nice summary of the features of the languages. Clear which solutions he was advocating! I would have liked a bit more on the architecture of the networked-application, though that was probably asking too much for talk this long. Will check out his blog to see how much of that is covered there.

del.icio.us: ajaxworld, ajax, RIA, notes.

AjaxWorld session: Bill Scott

Crafting rich web interfaces

Six principles for crafting rich web experiences:

  1. make it direct
  2. keep it lightweight
  3. stay on the page
  4. provide invitations
  5. use transitions
  6. react immediately

Make interactions direct: keep prompt and input close to each other. Inline editing. Discoverability: how easily can users discover what they can do with the interface. Readability is important: hide edit affordances until the user requests editing action.

Make it direct: drag and drop. Drag-and-drop has a large number of moments (variable elements); not easy to get right. Drag-and-drop often not very discoverable. Techniques for enhancing discoverability (see slides). Dont' use dnd for setting basic parameters, unless perhaps it's a game setting.

Keep it lightweight: contextual tools. Provide key interactions with as few additional steps for the user as possible. Identify and remove pain points. "Click weight" measure of number of clicks, how long it takes to find the click location, how quick the reaction is. Analyse click weight when reviewing an interface.

Anti-patterns. "Hovering cover" – pop-up label covers wanted content. Opaque icons ("mystery can").

Change-blindness - people lose context when there's a gap between page refreshes. Try to keep on the same page. (link to change detection puzzle).

Anti-pattern: Idiot boxes. Say things that don't need to be said to guard against idiot behaviour. Anti-pattern: hover and cover. Overuse of pop-up hovers.

Better to use inlays than overlays. Accordians - show info in context, but can hide new changes. Good example: roost.com.

Re-think paging: maybe use scrolling of components to avoid paging the whole page.

Keeping process flow. OK to inject step-by-step if the user really should be interrupted.

Dynamic invitation: make something look unfinished, engages user in next step in the interaction. Give a peek of next/previous items.

Transitions: grab the users attention and cause them to look somewhere. Make sure the users are looking at the right thing. Can speed up or slow down time. Show relationships. Focus user's attention.

React immediately. Good example wundrbar. parses natural language query dynamically, shows structured result. create a really tight feedback loop with user.

This was a really good presentation, rather spoiled by Bill having to go into hyperdrive to finish on time. He pretty-much skipped the last third of his slides. I would have happily listened to him for twice the length of time he talked for. Ah well. The presentation is available online.

del.icio.us: ajaxworld, ajax, RIA, notes.

Monday, October 20, 2008

AjaxWorld: Ben Rushlo and Rajeev Kutty

Designing for and managing performance in the new frontier of rich internet applications

Industry leader in web performance measurement (self-claim). Cannot retrofit performance at the end of a project, has to be built-in all through. Lots of factors changing performance management: browser as platform, page size, page complexity, languages, cloud, ... etc. Application life cycle much faster (1-2 months, or faster). User expectations have risen: always on, always responsive. Web 2.0 changes expectations.

Best practices

  • Have to test at every stage of the app lifecycle
  • Test from the cloud – where the users are
  • Test with a browser (what proportion of the time is spent in the browser engine)
  • Use the right metrics (use many metrics, avoid "pet metrics", avoid using a single metric

Web 2.0 performance challenges

Javascript files load one at a time (serialised). Minimise the number of external .js files. Don't put all javascript links in the header.

Client-side processing can take a very large amount of the time taken by a page load. Tip: identify and reduce client-side processing

Third-party quality (adsense, mediatrack, tracking, etc). Third-party code can slow down the overall page (does not go into a separate thread). Tip: get a SLA in place; put the third-party links in footer not header where possible.

Web service performance can vary - get SLA's in place.

Flash: balance size and number of flash files.

Basics: reduce the number of round trips (CSS sprites, HTTP keep alive, caching).

Measure, measure, measure.

Now available for free: KITE - Keynote Internet Testing Environment.

AjaxWorld session: Jon R. Doyle

Talk: Web 3.0 and the Age of Intelligence

Web 3.0 = "semantic web" or &guot;pervasive web". Examples from unified communication: what means are there available for communicating with a given individual at a given time. e.g. email, IM, iPhone, ... Web 3.0 2008-2012. Learning agents (web 4.0) estimated 2012..2015.

Benefits: convenience in personal and business life. System can make decisions about whether the phone rings or re-routes to different locations depending on user context, message content, etc. Lots of examples of changes in next-gen communications systems, especially basic changes needed at the network level (US-centric). I wasn't clear when the speaker was talking about what has been done, what is being worked on, and what should be worked on.

Summary: ubiquity good, walled gardens bad. Rather general, and a bit disappointing.

AjaxWorld: Ajax techniques for data visualisation

AJAX techniques for data visualisation

What can we do with push communications? Collaboration over the web with active data objects. Want a programming model that preserves designer and developer model. Use ICEFaces to translate between presentation in xhtml and app logic in POJO to Ajax.

Use ILog Views to generate Ajax calls to refresh visualisation incrementally. Can also use Comet and ICEfaces to incrementally push changes in one client to others.

Describing quite a bit of detail about how ILog jViews and ICEFaces integrate - architectural issues around both client-initiated and server-initiated content update. Not quite what I was hoping the talk was going to be about from the title.

Description of asynchronous update mechanisms. Browser is only permitted two connections to server (according to specs), so for multi-window push apps you need to pool the connections and share them out. Makes for complex Javascript.

Cleverly done, but I was hoping to hear more about the actual visualisations. The only example was a graphical view of a Gantt chart.

Ajaxworld session: Dave Meeker

RIA 2010 – next-generation user experience

History: 1995-2000 experimentation. Ways to make user experience less flat. ActiveX, java, etc. Working to overcome page-based apps, minimal controls, server trips. Not what we want to give the user

History 2000-2004: SOAP / web services, XML, flash, flex 1.0, ... etc. Set up the current field. Pet market: first example of complex rich interface.

2005-2008: revolution. Adobe buys Macromedia. SOA adoption. Ajax matures. Flex & Air. Users demanding good experiences. UI studies show better user performance with rich apps

2009-2011: near future. Web apps making use of GPU power. Blurring of boundary between web and desktop (e.g. Air). Cloud and remote file storage becoming ubiquitous. Mobile gets real - hard today because of plurality of platforms. Semantic data - is W3C semantic web vision "real" [ijd - not clear what real means in this context]. Multi-channel (tv, etc).

User experience design. Back-end capabilities have grown, now not a blocker for front-end capabilities. Users experiencing new consumer UI's (gmail, twitter, ...). Expect same experience at work.

Do we still need to call them "rich" UI's? No-one does just html anymore. Rich = not page-based, responsive, contextual, real-time, motion-capable. Why motion? Helps users to understand the state changes that are occuring.

Lots of technologies around (platforms, langs, libs) around. What else will have an impact? SOA - business logic exposed as services. Other application enabling services coming: image/video, AI/decision making, recommendation, audio, etc. Lots of startups providing their offerings as service endpoints.

Web apps getting more desktop-like. Desktop apps getting web connected (desktop widgets).

other trends: adding z-dimension to UI's. Not second-life, just using depth - info further away is less important. Cloud. Unbounded pages (page is larger than viewport).

Over the horizon: new forms of input. Ambient data to/from portable devices. Broadband everywhere. Connected devices. Not just about technology any more.

Focus should be user not technology. What does the user really need?

Demo financial reporting. Used flex. Ajax couldn't handle the data volume. Nice use of 3d browsing. Demo example of replacing Siebel ERP interface with Ajax.

Advocacy: use hybrid-teams with multi-skilled individuals. Encourage people who want to transition between skillsets (programmers to designers, software architect to info architect, designers to programmers, etc).

merapiproject.net - AIR to Java integration

AjaxWorld keynote: Matt Quinlan

Keynote: Get Rich Quick

Hard for business owners to translate from what they actually want to functional requirements. Challenge is to give what they need. To the user, the interface "is" the application. Separate two elements: aesthetics of the interface and the user experience. First isn't hard to convey, second is.

Answer agile development [ed: who didn't see that coming?]. But: problem = phase 2 development often requires refactoring or redesign of phase 1 datamodel. Use agile approach to build UI in phases without backend development.

"High fidelity prototyping". Look for user's emotional response to proposed design. But building prototype has to be efficient.

Prototyping strategies

  • Paper. Pro: fastest. Con: only for early phases, doesn't work for distributed teams.
  • static html wireframe – lots of effort, too much to throw away
  • photoshop - – good for aesthetic design. Still hard work. Lo-fidelity for rich apps.

    Challenges

  • HTML scripts – generated server side, so how to handle that in a rapid prototype. Don't want to have to spend a lot of time programming / simulating server side code
  • JavaScript
  • Ajax - either have to mock ajax calls, or build server-side mocks

Ideal solution

Build a prototype in days or weeks. Build a prototype that is not throwaway, but will be the UI for the final app. Expectation management is key: users must not believe the app is done.

Goals: Avoid CGI. Has to be simple. Easy to mock, and replace post-prototyping phase.

Appcelerator solution: unified widget framework – extend HTML. Large lib of built-in and third party widgets, including flash and flex. Javascript: RIA's include lots of Javascript (e.g. google maps > 6k lines of javascript). Lots of javascript cruft. Three core tasks: DOM manipulation, event handling, ajax invocation. Web expressions: on="condition then action". Lots of built-in condition types – DOM, keypress, history, drag/drop, iPhone ... Actions – scriptaculous effects, CSS, custom javascript, publish custom message. Use of observer pattern, more similar to desktop GUI's. Novel to HTML interfaces. Message broker built-in to client side code. Can be extended to send messages to server-side as well, through service broker. Server-side implmentations of service broker in Java, .net, ruby, python, perl.

AjaxWorld: keynote Scott Guthrie

I'm at AjaxWorld in San Jose this week. I'll try to keep up with the sessions I attend here on the blog.

Scott Guthrie - Enabling Great Experiences

Team leader for Silverlight 2.

VS2008 focus on web support. includes intellisense support for open-source javascript library (e.g. jscript). LINQ for querying many types of data backend. Visual Web developer - free edition.

Silverlight

Goal to make install into non-Silverlight machine in 10 secs.

Two core scenarios: media support (esp. video), and RIA developer support. Adpative streaming: publish at multiple bitrate, client can pick the best bitrate on the fly.

Cut down version of .net. Cross-platform languages - can run c#, vb, python, ruby, etc, on the client.

Cross-site calling: can call webservices on servers other than the point of origin.

Standard form controls, and higher-level copmonents such as calendars, tables, etc, or can use plain html UI and run the script faster in silverlight. Skinning model allow designers and developers to work more effectively together - designer and developer working on same project structure (visual studio for dev, MS expression for design)

Demos: hard-rock cafe deep zoom demo. Rich UI example for healthcare info. cute demo of WPF components with graphics effects, delegates work to GPU so CPU utilization does not dominate.

Slick presentation, nicely done tools.

Wednesday, October 08, 2008

Great tutorial: maven and FlexBuilder

I seem to be forever learning new technologies at the moment. Recent forays have taken me into Ruby (and Rails), Maven, Restlets, Wicket and now Flex. Often I feel like I quickly learn enough to be dangerous, but not enough to really feel like I'm really grokking a subject ... that usually comes with time and practice. Case in point is Maven: I've used Maven on a number of recent projects, and on the whole I think it has been a useful tool and a boost to the project. I also feel like I don't properly get Maven in depth, so when I have to add a new capability to a maven build, I have to hit Google for help. That's why I really like Jeff Maury's tutorial on integrating Maven with FlexBuilder. Not only does Jeff hit the spot with the technical focus of his three articles – it actually is very useful to see how to have both IDE-based and build-based approaches to Flex in one package – but the explanations of the underlying goals and patterns is a very helpful reinforcement of the principles of Maven-based multi-artifact builds. Kudos Jeff!

See:

del.icio.us: maven, flex, tutorial.

Tuesday, October 07, 2008

Maven Exec Plug-In for running POJO applications

I needed to run a plain Java application as part of one of my maven projects – it's a tool for priming an RDF ontology database with some fixed content – and it took me ages to find the appropriate maven incantation. I'm blogging the answer, in the probably vain hope that it will give my search terms ("maven2 run pojo java application") some extra googlejuice so that other seekers have a slightly easier time of it in future. Anyhoo, the answer is the Maven2 Exec Plug-In.

del.icio.us: maven2, tips, java.