In need of free craps online

The software company I work for is exactly the same – budget/time over “proper” proceedures/methodologies.

If the developers here stopped using Echo2/GWT/YUI and said “We’re going to create from scratch, but it’ll take us a year to learn JavaScript, DOM, CSS and all the browser differences, plus another year of development doing market research, usability studies, focus groups, paper prototypes…” they’d be out on their ears as manangement think that:
1. because of the longer dev time our software will be behind that of the competition
2. all that touchy-feely guff is only there to give strategic product/marketing companies something to do
3. they’ve been developing software this way from year dot and no customer has ever complained our that software isn’t “humain, “usable”, “user-freindly” or whatever the latest fad is
- but that’s not the fault of the Toolkit(s) of choice it’s the mindset of the software company…

I like to have my data locally–that way I know I can get to it. If my data is on somebody else’s server, they may be down for maintenance or due to, gasp, some attack/occurance.

Sure, the mail server could be down too, but one less potential problem is a good place to start in my book. The Software as a service model is good marketing right now, but my data on Basecamp helps me not if a hurricane hits my area and I can’t connect to it…

I’ll just download my e-mail (in text format please) so I can deal with it on my machine. I’ll keep my other data local. However, if you don’t have to have the data (personal e-mail maybe?), then network storage is fine.

It is all relative..

Whether a brower-based application is developed using, Echo2, Dojo, YUI, GWT, prototype+script.aculo.us etc, etc, does not mean that it isn’t possible introduce “new things” or “methods”. It is the mindset/processes of the developer(s)/software house(s) that can stop innovation – this doesn’t make gui toolkits bad – just like Flash isn’t 99% bad. Toolkits are there to speed up development (where possible) – but it is the choice of the developer(s) to sacrifice “innovation” (with respect to HCI) e.g. “I’ll not bother using any focus groups, paper prototyping, user testing, etc, etc I’ll just copy V 1.0 source and add a new button, we need to get V 2.0 out by January…” – the toolkit doesn’t force the developer to do anything.

Aza’s point (or the point of the extract that’s being commented on) was that “The desktop-like web toolkits being developed today endanger innovation by entrenching us in familiarity of the past. ” I stand by my view “Desktop-like web toolkits that are being developed today DO NOT endanger innovation – bad or incorrect software development practises do.”

There are well documented methods/conventions relating to the process of creating any human-computer interface. A good interface is transparent (doesn’t get in the way of a user accomplishing their task(s)) (and it makes no difference whether it runs in a BRE or any other “runtime”).

For instance, a Java Swing app (with a windows L&F) will look predominatly same as another Swing app (with the same L&F) it doesn’t mean that the Swing Toolkit is bad – what it means is that particular software house may not have done any user testing (and used the Toolkit “straight out of the box”) or that what they did do, resulted in their “target audience”, “average user” (or whatever you want to call “them”) wanting something that looked “straight out of the box”.

In a similar vein, Flash was not 99% bad – 99% what developers/designers produced using Abobe Flash was bad.

If user testing shows that an Accordian Component used to display a certain type of information is more usable (faster, easier to remember, etc, etc) than a Tabbed Component, then so be it or that navigating a file system using a “Component” that looks like you’re travelling down a worm hole to a different part of the galaxy is more usable thats great too.

Desktop-like web toolkits that are being developed today DO NOT endanger innovation – bad or incorrect software development practises do.

just my 2 cents

Ajax provides better use experience and allows users to replicate desktop application and deploy it over the web. Developers and application provides will not take advantage of all the new design capabilities when migrating their applications. You will see many applications make use Ajax or other RIA technologies to replicate Win32 or Swing applications down to the last detail. The reason is it is extremely expense to retrain large groups of people on new UI design metaphors.

For those who have the luxury of create an application from scratch, it may be an option to explorer new designs, but you need to look at the usage model. Are people heads down, key board only, what are the accessibility requirements and so on?

Take a pragmatic approach is always best when dealing with usability.

My feeling is that web applications are converging to desktop-like applications whether we like them to be or not (i.e. gadgets/widgets from Google/Yahoo! Konfabulator, Flex 2.0, offline access in Firefox, etc.). However, I am not sure how that hinders creativity when going from the web to the desktop model.