Showing posts with label Web. Show all posts
Showing posts with label Web. Show all posts

Monday, September 30, 2013

A practical UI note on the order of input elements in a form

Input elements in a form are usually arranged in their natural ordered, that is: an item that seems to come naturally first would come before another one which seems more naturally to be second. This is of course subjective, but most people would agree that First Name should come first.

Recently I got a feedback on a form, sent by a heavy-user using the specific form many times a day. His request was simple, yet I've never thought about that before. He was asking if we could be kind and helpful to reorder some of the input input elements in the form, so items that require the keyboard would be in one group while items that need only the mouse, such as check boxes and radio buttons, would be separately grouped on their own. This would allow him easier and quicker fill of the form, he said.

(One can argue that the easiest and quickest way to fill a form is by using only the keyboard. But it appears that this user, as probably many others, is good with the TAB key to move between elements, but he is not aware or not keen of using the arrow keys for navigating between radio buttons and space bar for checking or unchecking a check box).

In order not to break the natural order of things (keeping first name first, and gender male/female reasonably up in the form) the grouping should be done in areas of the form, which comes to my new practical note to be phrased as:

Try to avoid too many switches of keyboard input elements to mouse input elements, if those can be naturally ordered into reasonable sub-groups to avoid the switch. This would allow a more rapid fill of the form.

Thursday, August 13, 2009

When a bug makes you crazy

This week I was sitting on one of those bugs which almost make you scream. Something is wrong, but you cannot find what creates this f-word behavior.

I was working on some web page example for some Taglib framework, but the page insisted on having an extra element that I didn't create. And when picked using FireFox, it pointed at a node in the XHTML that I'm definitely not rendering...

Step 1
Nothing in the code should make this happen. First suspicion is that I'm running an old instance, so I'm running a clean+compile and restarting the server, then when this doesn't change anything I'm adding a printout just to make sure. The new printout appears. Damn! I'm running the code that I'm looking at, but nothing there seems to be responsible for this result.

Step 2
I know that in order to debug I need a theory. But I cannot raise any theory, as clearly the result that I see is not something that is in the code... So I start playing (though I know it's not the methodic way for debugging, but I'm trying to play methodically). I find all places where I render this kind of element that is being rudely added where not belonged and I mark them each with a unique id. The id appears. Now I can identify the exact place that is responsible for this behavior, but I can't understand why it happens. An XHTML tag is added in a place in the document that surely I'm not printing.

Step 3
It took me some time. Maybe too much time. But I understand now that FireFox tree view of the page is cheating me... The element that FF is presenting at a certain place on the tree cannot be there. I'm not printing it there. Suddenly a strike hits me: GET BACK TO THE BASICS. Instead of using FireFox to locate for me the wicked node, let's view the source of the page. How simple and basic, though yet I spent about an hour before thinking about this simple thing.
And indeed, when viewing the page source I see that the problem is that I'm opening some HTML tag somewhere and not closing it, but FF closes it for me way beyond this point, creating a very strange node that I didn't create. In the treeview of the page FF presented a tag with a start and an end, while I accidentatlly opened a tag at some point and didn't close it. Now it's much easier to see the problem. And I also note that indeed FF showed that there are errors on page, with this error listed.

Moral

  1. When the tool you debug with shows something that you cannot explain, go back to the basics: tcpdump, sniffer, printouts. The debug tool may be misleading you!
    Believe only to bits and bytes, not to any fancy tool.
  2. If you are working on a Web page, first look at the "errors on page", if you always insist on first fixing these you will save valuable time.
  3. When a bug makes you crazy look him in his eyes, tell him that you will beat him. Don't show any weakness signs as these bastards know well how to recognize such signs.

Thursday, July 2, 2009

IE is a pain in the ass

Back in the old days when there were Internet Explorer (IE) and Netscape, everybody knew that it is very difficult to write something that would run perfectly on both. But since it was only two dominent browsers not many pointed the finger at IE. It was just that the two are different, life is challenging what could you say.


Today, when you have Opera and Chrome and Safari and FireFox -- ALL BEHAVING THE SAME -- and IE in his own realm, it is much easier to point the finger.

And here are some who do point the finger:

and there are more, just google for IE sucks or IE pain in the ass. Which it is, for most web developers.

It's nice to see that the other browsers do have a strict implementation according to the W3C standards, resulting with uniform behavior and ease of development. It says good things on the W3C standards being well defined and about the discipline of the coders of the other browsers, as opposed to IE.

Microsoft needs to drop IE altogether, start with a new code base and a new brand name, the current one is ruined.


Tuesday, September 2, 2008

Google open sourcing their new browser, Chrome

Google new browser, Chrome, is the talk of the day. And the comics are indeed great.

Some were enthusiastic about Google opening this vast project as an open source. Noble indeed. Google themselves are feeling virtuous about it, or at least want us to feel that way. After all, a great tool like this (no one really seen it yet, but they do know how to create a buzz and I guess it will be indeed a good browser) – by releasing this great, superb, new-era browser as an open source, anyone can take it and adapt it to his needs, even Microsoft can, and maybe will even do.

So why did they do it? Why to open source? You can give it for free without opening it...

Slide 37 lists the noble arguments.




But could they really?
Do they have the option the ship a proprietary browser?

NO, because they don’t have one.

This new Chrome browser is said to be built upon WebKit and Mozilla projects. Both projects are open sourced and require derived work to be open as well (section 3.2 in
Mozilla Public License and 2 of the LGPL).

They could have find a way to keep some of the code closed, like maybe the V8 javascript VM. But it would probably be too risky legally. And they might need their lawyers ready for Android issues (or for buying Sun).

Bottom line:

No need to be too cocky about open sourcing. As nice as it is that you open it, you probably had no other choice, other open source initiatives worked hard on writing parts of your code.

Monday, July 21, 2008

To AJAX or NOT to AJAX?



I had today a discussion on when to use AJAX and when not.

The idea is simple: the plain old request-response is usually a good thing, if you keep your pages small, which you should (CSS and JavaScripts should be external, thus a nicely built pure HTML page should be around 10-20K, not more).

The plain old request-response keeps your url meaningful - the state of the page is reflected by the url, which is a very good practice to follow.

The plain old request-response keeps your Back button function as it should, without any unnecessary tricks.

The plain old request-response keeps all your content available for search engines, which is usually what you want.

The plain old request-response keeps your user using what he is used to. No surprises.

So - when should AJAX be used?

  • Auto-completion
  • For fetching partial long lists based on some initial input
  • Quick response to something insignificant, like showing the current results of a poll right after your vote is done, blocking you from re-voting (not that you cannot delete your cookie or session identifier and go back to the page to vote again, usually the vote is not registered per IP address)
Some additional insights on this topic can be found here:
http://webdesign.about.com/od/ajax/a/aa092506.htm