Find your next scenic drive!

September 28, 2004

Thunderbird problem with receiving e-mail...

I have been using Mozilla-based e-mail products exclusively since around 0.7, in the days where it was no where as stable as it is now, but yesterday, I had a strange error at work, where Thunderbird 0.8 just stopped receiving e-mails. I had seen problems like this before, but after restarting it, it would work. But not this time.

After playing with it a bit, I decided to Google on it, and I found this discussion on MozillaZine, I tried the suggestion of deleting some messages via another mail program, but to no avail.

I looked through the configuration directory to see if there was anything locked or usual, but nothing seemed out of place. I then decided to rename my mail server to something that would not resolve, and after restarting, it still did not complain about the unresolvable mail server.

I decided to play a bit with the settings, and this is when I finally got it to work. Under the Account Server Settings, I:

  • Unchecked “Check for new messages at startup”
  • Unchecked “Check for new messages every X minutes”
  • Unchecked “Automatically download new messages”
  • Unchecked “Leave messages on server”
  • Checked “Fetch headers only”
  • Changed the server name to something that is not resolvable.

When I restarted Thunderbird after making these settings active, it complained about the server name not being resolvable. I then changed the server name appropriately, and tried it again, and it finally started receiving my mail! I changed my settings back to my normal settings, and it has been working ever since.

Thunderbird somehow gets into a state that it cannot get out of, that stops mail from being received. Hopefully there will be someone who can find some real reproduction steps so that this bug can be squashed, as it seems to have been there for a while already. But it looks like an unlikely bug to occur.

I have been using Thunderbird exclusively and extensively since 0.2, and this is the first time anything like this has happened. This speaks for the quality of the program. If you have not yet tried, it is definitely worth a try!

September 15, 2004

Web Viewer Eye Movements...

Meryl Evans has posted an her comments (full comments here) on a recent study called Eyetrack III. This study evaluated the eye movements of a number of people on various web sites to see the areas of a web page that are most valuable and the styles that are most eye-catching.

Some of the results are a little surprising, such as smaller fonts in short paragraphs encourage reading instead of skimming. The article also mentions how users spend more time on text-based advertisements than on graphical advertisements; I would think this is natural, since your brain can evaluate the page very quickly and identify graphical advertisements faster than textual advertisements, and so we probably need to look at text advertisements longer to process that it is an advertisement.

While the old saying states that a picture is worth a thousand words, it is interesting to note that this particular article states that graphical representations are better to clarify concepts that readers do not understand, whereas data is more likely to be absorbed when read.

The analysis on the web site hot spots was interesting, but this also seems that this is our instinct. In addition to the fact that many languages are read from left to right and top to bottom, most web sites are also setup in this fashion, and while some of these sites may have done their own usability studies, I am sure that a good portion of this is applying a similar look-and-feel used on other web sites, since introducing a completely new interface could discourage some users from using the service.

While this information is important and very interesting, I whole hearted agree with Meryl's comments on her blog, which essentially is use the above as an influence, not a rule. Even in the articles preface, the surveyors indicate that the study was “wide” instead of deep, but nevertheless, I think it is worth a read.

July 13, 2004

A really fast fix... Or was it?

Many people in the Mozilla world are highlighting how fast the Windows shell vulnerability, such as MozillaZine.

Most of the focus has been on this, however, recently, there have been several people pointing out that this bug is over two years old, including this post from the same article. The first time I heard of it was on the same blog that announced the timeline; in this piece, Adam suggests that the fix is a really a band-aid, and proposes some ways to really fix the bug and prevent others like it.

Arguably, this bug is not really in Mozilla, but more in the fact that Mozilla uses a component that allows the exploit to exist. Specifically, Microsoft Word and MSN Messenger have the same issue, and like many other exploits in Microsoft's products, this will probably go unfixed for a while. To make this more concrete, Meryl Evans compares to exploit to another application.

This does beg a question of how many other bugs are like this in the current code, but on the plus side, at least they fix their bugs...

June 28, 2004

A Look at WebForms 2.0...

At the beginning of this month, WHATWG was created by the Mozilla and Opera organizations, and as discussed at MozillaZine, they are presently working on a few new specifications that aim to extend current functionality, instead of the W3C's pushing for something completely new.

Working with something that is backwards compatible is always better than starting something from scratch, especially since the goals of the aforementioned specifications (as stated here) is to be used on Web Applications, such as Amazon and EBay. While some of the web's users are comfortable with installing new applications, there is a large segment of users that are uncomfortable with this. In a recent discussion with a friend at work, he described to me how he was designing a web site for a friend, and decided to place a white paper in a PDF format, however, his friend quickly objected, stating that with PDF, you have to download some third party tool and it is a hassle. Creating a backwards compatible solution would be idea in light of which, albeit tricky.

The first Call For Comments of the Web Forms 2.0 specification was posted yesterday and it is very interesting. It is like making the current set of types richer, in an attempt to blur the difference between a Rich Text Application and a Web Application, such as Joel On Software's recent article talks about. There is still some work to be done to make this completely blurry, but it is going in a good direction.

For starters, the ability to have use the form attribute within a type allows two or more forms to be interlaced. This is similar to specifying the way that a form is processed via submit buttons instead of the form. The former I think will allow design to be more free, whereas the latter will result in cleaning up pages which ask for the same information for a slightly different function, such as subscribe and unsubscribe pages.

The date and time extensions to input is a welcomed extension. The javascript-based calendars that we have been using are nice, but clunky and do not always work so nicely. The required attribute will also save some javascript, and hopefully improve some of the user interfaces created when there are required fields (already the CSS3 UI extensions are nice). Likewise, the Google trick of focusing that is done via javascript will now be done via the autofocus attribute.

Some of the extensions for numbers, ranges, and patterns are also welcomed extensions, which are currently done via javascript or on the server side. Particularly, implementers could implement it via a spin-control, making the context far richer. There are more areas in what is described that could permit this, such as the ability to upload a number of files and a file filter will allow a Open Dialog box to add multiple files of an accepted file format within a directory, simplifying implementations such as Geocities' File Manager. To complete this integration, we now have the help attribute to list a URL to load for help, potentially implemented like Tooltips.

Even with these stricter input tags, the specification adds some form validation controls; in the event that some of the new attributes are not enough to prevent invalid input, the new validation methods seem to simplify some of the previous javascript that had to be written.

The output area is interesting also, since sites like Online Conversions are presently doing this via an input element, and sites like XE force you to have a button, perhaps because of this issue. The example is done via a span element, however, an output area will make its intention much clearer to HTML maintainers.

The autocomplete attribute is interesting, in that it will disable the client-side feature of storing some fields. I foresee this attribute as being ignored by browsers.

The new data attribute allows you to fill in certain types by using an external data source, such as a remote or local file. Using a remote RDF file, I can see this as being useful in some contexts.

One of the most interesting features proposed is the Repeating Form Controls, of which they have created a demo. I see this as being extremely helpful in creating web-based database entry systems, such as a database query engine or, like the example in the specification, an invoicing application. The controls that are described seem very powerful, and appear powerful enough to do even some non-form related repetition.

And to add to this, we now have the ability to submit forms as XML, which will simplify some of the CGI manipulation that must be done presently. There is also the ability to FTP, e-mail, or even SMS the form data (amongst others).

There was one control that I was expecting to see what I did not see, and that is the control for a combo box. There are many cases in development of applications where a combo box is really useful; it provides both a default answer selection and the flexibility to enter other information.

I see that the future of forms will be easier for the content developer, mainly because there is substantially less javascript, and I see the users getting a more better and more consistent user interface. I look forward to using it, except that I am bit concerned of the migration to the new platform; this will hopefully be smoother now that the Internet Explorer team is recreated. I appreciated their humour (or so I assume) of how User agents can handle authors of invalid HTML ;-).

Earlier Entries

<  1  2 


Recent Posts