Digital Web Magazine

The web professional's online magazine of choice.

Devising a new paradigm for usable, maintainable Web applications : Comments

By Ka Wai Cheung

October 20, 2004

Comments

Aleksandar

October 21, 2004 2:37 AM

There is no reason to use “span class=body” with inputs, when there is a perfectly fine element for that purpose: label.

Otherwise, nice view from the programmer’s corner.

Fred

October 21, 2004 4:50 AM

I think what you are describing is a work in progress at the Web Hypertext Application Technology Working Group : Web Forms 2.0

I strongly believe THIS is the next big step in client-side coding.

Paul Carpenter

October 22, 2004 2:52 AM

I was a little bit confused by the point being made here. It sounded more like the ‘users’ referred to were actually developers, rather than Joe Soap sat at home actually trying to use the web application.

An Object Orientated approach will not make the slightest bit of difference to the end user – all they will see will be what they always see: a few textboxes.

OOP offers nothing to the end user – only to the developers who use it to build the app. Until and unless HTML forms have more features than text boxes, radio buttons and drop-downs, web apps will remain exactly as they are, whatever strategy is used behind the scenes to build them.

Usability actually stems from identifying the minimum amount of information required from the user to fulfill the task they need the app to do, and then designing the easiest quickest route for them to do it.

Small Paul

October 22, 2004 4:41 AM

I think the idea is that if developers use an object orientated approach, then their code will more accurately reflect the way the user sees the application, and that this alone will make applications more likely to be more usable – or at least make it easier for developers to assess how usable an application is, and make it more usable.

Small P

October 22, 2004 4:46 AM

Having read the last part of the artilce again, I think the missing part is that (X)HTML and JavaScript already allow separation of structure of presentation and behaviour. Granted, your structure is limited by the elements present in (X)HTML, but grouping form controls? <fieldset> Labels? As mentioned above, <label>

Like everyone else, I imagine when better, more flexible markup languages or equivalents get going, there’ll be lots more possibilities. But there’s a reason why HTML is so popular. It’s because it’s there. It’s supported. And it degrades well on older machines, which will still be around in consumers homes for quite a while. So don’t hold your breath.

Luke Shingles

October 22, 2004 6:10 AM

Aleksandar – “There is no reason to use “span class=body” with inputs, when there is a perfectly fine element for that purpose: label.”

I agree, it was disappointing to see that forms weren’t being used properly in a web standards focused article. The input elements will also need to be contained in a block level element (eg. p) for strict doctypes.

I don’t know why but the label tag is incredibly rare. All the standards sites seem to get it right though. It’s a lot more important on checkboxes where the usability improvement is huge. It’s very annoying having to click a checkbox instead of the text next to it, especially when the text is the first thing you try, requiring multiple clicks.

scotbot

October 22, 2004 6:28 AM

Javascript is fully OOP compliant. It offers inheritance, encapsulation, and you can create your own interface contructors. The syntax may not be the same as Java or JScript.Net, but it is still object oriented. Visit http://www.crockford.com/javascript/javascript.html to find out more.

Ka Wai

October 22, 2004 6:34 AM

Thanks for all your comments. You all make great points.

To address a few things, I am referring to the application user when I use the term “user” (not the developer). Small Paul is correct in his interpretation- I am suggesting that a more object-oriented approach to markup code can foster the kind of thinking we need to make applications more usable (and maintainable). On second thought, I might be better off focusing on usability and maintainability in separate articles.

Secondly, by know means am I suggesting we should abandon anything the web community has done in terms of the progression of HTML to XHTML and CSS. It is certainly the way we have to go, it is being supported, and gets us much closer to building easily maintainable web apps.

However, I am offering a slightly alternative heuristic that can allow us to use some standard object-oriented concepts (interfaces, inheritance) to create very reusable code. Instead of using a set of standard labels, object-oriented code would allow us to create our own labels (i.e. a grouping label like <date> rather than <fieldset> which is instantly more descriptive) and define their functionalities in any way we want (validation, for example). We can then use inheritance to attach standard <input> boxes to the date’s month, day, and year fields. So, from the user perspective, it doesn’t necessarily render differently, but from the developer’s perspective it is thought of as a date.

I admit, there are certainly some consequences of what I am suggesting here, but hopefully it offers some insight into an alternative way we can develop presentation code.

Gabe

October 22, 2004 7:04 AM

Paul is correct, Object-Oriented Programming is not a silver bullet for any engineering conundrums, much less HTML muddiness. The fact is that OOP has been marketed heavily for a long time, but the improvements that come with OOP are not inherently OO in nature, it’s just that there hasn’t been much language development in other paradigms. For many many web applications, OOP is overkill, you can achieve the same encapsulation and sensible design with a standard library of functions. Sure, you can put them in a class, but is it really necessary? Please see http://www.geocities.com/tablizer/ for more in-depth discussion.

The main way to get better web applications is to simply hire people who know something about usability design. If your programmer doesn’t have a good feel for it, then you need another head. Secondly, do usability testing! Sit people down and have them use the app, it’s not hard and it makes all the difference.

Now, from the technical side I think Ka is onto something by defining behaviour outside of the HTML. Down in the trenches I have my own method of propagating form values, validation, and database population that require extremely low code overhead (I’ve developed a sweet personal PHP library). My next step is to develop a richer way of specifying forms. It may be unofficial HTML tags that I strip and parse from a form, or it may be a straightword PHP definition that generates the HTML form automatically, or it may be something in between like a Smarty template.

Ka Wai

October 22, 2004 7:23 AM

To Scotbot’s point… yes JavaScript does have OO capabilities (though, as your link suggests, its rarely understood). However, there’s still a bit of a disjoint between HTML and JavaScript. You can create objects in JavaScript but you can’t create objects in HTML, or have custom HTML tags be interpreted directly into JavaScript(as far as I know).

I’m trying to take a step back and figure out a tighter integration between markup code (HTML) and behavioral code (such as JavaScript) so that both sides are object-oriented with each other.

Is this overkill or practical? That’s up for debate.

scotbot

October 22, 2004 9:34 AM

You can create your own tags and use JS to intrepret them and render the appropriate HTML. Here’s an example from Peter Belesis of Dynamic Lab which generates a calendar object from a clientside custom tag: Pop-up Calendar 1.2

In this sense, you could quite easily create various types of fields which all behave differently. Besides, there are always Microsoft’s DHTML Behaviours (HTCs) for the not so M$ shy!

Chad

October 22, 2004 10:03 AM

I’m a web designer working with a web dev team that has built their web application using ASP.NET, SQL and C# using many layers of templates and user controls (ascx). I have found that many of the ways ASP.NET needs to refer to objects renders them difficult to refer to them appropriately in the CSS or DOM.

For example, when something like a DataList has an ID of “MyList”, the actual rendered ID in the XHTML is “MyTemplate_MyParentUserControl_MyList”. This means a class is needed rather than using IDs for CSS, and refencing those object through the DOM becomes rather annoying. Anyone else dealing with this? Any suggestions?

Hugo

October 22, 2004 12:20 PM

The HTML and Javascript

bucky

November 11, 2004 1:05 AM

um, oop doesnt solve any problems design wise, only introduce new ones that you must sove…. Rule #1, never rely on javascript for your application or it will fail. GG Gmail.

scotbot

November 11, 2004 5:42 AM

bucky: not an issue if you use HTAs as your rich client. :p

Sorry, comments are closed.

Media Temple

via Ad Packs