Ask yourself, why do HTML forms work so well?
Ok: Self, Why? (Self answers) Because they've been in place since very, very early in the game. Basic HTML has even differed over browsers at various times (blink, level of table support, tables cell fill, table height options, marqee, etc.) Those things are to be avoided, because they weren't uniform early (or even now in some cases), and those browsers are still in use. Some people - mostly Linux people, I think - still use text browsers. It's not because HTML is standardized - because it's not, specified most certainly does != standardized - and it's not because "everyone conforms", because they most certainly don't. It's strictly because all the incompatable, browser specific gee-gosh stuff is ignored by good HTML writers.
It's because they were standardized and every implementation has been given time to conform to them well.
As I detailed above, not really. Every implementation conformed pretty much right out of the gate, discounting the really primitive days.
CSS and XForms are very similar. They aren't implementations like ActiveX, Java, Flash, etc. They are specifications. This is an important distinction that should result in a greater ability to present an application that works in all client environments.
They should, eh? Like PNG did? That was a specification. A decent one, too. Useful. Timely. Great (and immediately useful) example implementation. I would have loved to be able to use it... real alpha is a web page artist's dream. We supported it very early. So did other graphics companies. Free technology, even. Could hardly have been any better (unless it supported animation, but that's another rant.) Fell flat on its face. By which I mean, if you use it on a web page, very few people will be able to see it as you meant them to. (cue wet splattering sound)
What makes something useful is:
Not specs. Not implementations. Not free code. Not hope. Not even shiny, cute as heck little icons.
And indicates a 1999 understanding of what makes a good user interface.
Why, thank you. :) I'll bet you thought that was a putdown. I'm delighted that you intuitively understood that I have ZERO respect for the Interface Nazi Party. I'm mainly interested in functionality. Turns out, my customers are too. What can I do with this? What can they do with this? It's my little business secret. There are a whole bunch of people out there who want graphics software written in something that goes fast rather than some object-oriented pile of slow as molasses, bug-infested building blocks. Who don't care what the icons look like, or if the window is some bizzarre shape, or has "skins." What they actually want is speed, power and the ability so that they can make nice graphics. So my secret is out. I'm not worried, though. The only, and I mean only, two companies that have anything that remotely competes with our stuff are both hopelessly stuck in the "You'll need a faster processor to run that, sir or madame" loop, and I couldn't be more pleased about it. :)
But UI design has advanced beyond this point.
This is one of those perspective things. You see advances. I see major applications getting slower and slower. On the web, I see plug-in stop and go-ism. If you visit one of our web sites after you upgrade to a faster computer, or if you run our software after you upgrade to a faster computer, what you'll get is faster browsing and faster application response. It's a freaky thing, I know - when other companies keep burying themselves in the latest "use-every-cpu-cycle-tech", we keep writing tighter, more efficient code, so sometimes it is true... we're not linearly faster with your new machine - we're even faster than that. That, my 2004-interface favoring correspondent, is way cool. And even better than being cool, it sells. :)
The problem, as you've pointed out, is that the proper client environment doesn't exist a lot of the time.
Agreed. If it's not part of the base standard, I say, don't use it. Period. If you want something new, then start something new: Create a new web system that is not HTML at all. Create a new browser that can surf it that is not an HTML browser. Make sure all the stuff you want is in place, then launch the thing to the public. Don't subject the not-very-intrepid user base to creeping featureitis until nothing, anywhere you go, works precisely the same way. If you've got something useful and can get it universal, you'll be an honored person - instead of the poor sot who every user curses when their browsing experience gets shot in the arse because they don't have a plugin, an activex (I call activex "bug-ins", but that's just me), JAVA, visual freaking basic, Flash, or what-else-have-you-not.
And that's where standards come in. We need to give developers standardized ways of doing all the things they've become accustomed to doing in non-standardized ways.
Ok, fine. Just don't put it on the HTML web and continue to screw up the user's browsing experience. Start a new web or something else, and make a new app to browse it. Thanks.
I imagine that xL's comment about table widgets has something to do with this. He's probably used some widget library while creating a non-webapp and seen how useful a sensible table widget can be. So, when it comes time to implement a webapp, it's annoying to have to hack something together.
Yup. Absolutely. So it sure is a good thing that there is no reason in the world to have to hack anything to address these kind of interface issues in standard HTML/forms, or I'd have to be annoyed right along with the rest of you. But I'm not. It's not even a slight challenge. I'm not saying you can't find something that's hard to interface for business data; you probably can. But this sure isn't it. I can think of multiple solutions, and so can tons of other people, witness the very nice pure HTML email interfaces around the net.
There's another major benefit, too. If you do server-side processing, and there is a problem, you can fix it. Immediately. At 3 am with almost no setup, maybe even before another user ever sees the problem. If you do client side processing with (insert tech like Java or Flash here), and there's a problem - security, UI bug, memory leak - you generally cannot fix it, because you can't fix, or get at, the user's plugged-in-engine. When you use server side smarts and basic browser functionality (and by extension, when you write your own application code instead of using other people's building blocks), you can fix things when they break. You don't end up with an uncontrollable, sticky situation where some of your clients have broken stuff, and others have working stuff. You can fix it, you can solve their problems, and you can be the hero instead of the sod.
Anyway, I do appreciate the response, and the opportunity to speak my mind on these issues to you and the few others who have shown interest in the thread.
[ Parent ]