"Transfer time is less than 109 minutes with a 28.8 modem"

This was the message I was presented with, when I was sending a file to a friend of mine through Microsoft Messenger (v6.0.3 for Mac). This kind of messages is what I consider to be an interesting point of discussion about how interfaces are designed and often forgotten.
Of course this kind of message was always there, either in this application or in another, but the fact that I never payed too much attention to it makes me think that this kind of message was never relevant in the first place (at least for me). It would be considerably more interesting if the information was appropriate and adapted to the current situation, i.e., if it wants to go further and guess how much time it will take to perform a file transfer, at least should do it by using any of the following strategies (in my opinion):

• "Learning" the connection speed from past transfers;


• Simply calculating the speed based on connection settings specified by the user (like many video/audio streaming or P2P software);


• "Asking" the operating system how fast is the connection speed;


• By giving some sort of estimation using a connection speed as a base for comparison.

Messenger decided to follow the last option, and unfortunately either the persons who did it, already understood how useful that message was that they even forgot it is still there... or they still use 28.8 modems in 2007...

Of course this was only a starting point of discussion, and many follow this example. There are many software applications nowadays that are very feature-rich but so feature-fat that developers often forget about the user interface designing challenges and issues. Developers often focus on how their software is so feature-rich that if they applied a GUI profiler to analyze the user interaction with their software, like web developers do with web loggers, they would notice how many mistakes are performed and how much (big) the part of the software that is completely unused due to the lack of interest and effort on how interfaces are designed.
Some people say software should be feature-rich, if it is to be useful; others say that it should be simple, and easy to use; and others, like myself, think that it should be a mix of both worlds: it should be feature-rich, yet hiding all that is unnecessary for the current condition of use.

Diabetes classification

The purpose of my current assignment at university is to correctly find an automatic way to perform a diagnosis based on some patient attributes and test results. The field of Knowledge Discovery and Data Mining has always fascinated me namely the challenges that are imposed to us when we decide to take an analysis like this first of mine.
The diagnosis is about Diabetes Mellitus, a common disease which affects millions of people in the whole world. Much is already known about it and much is already scientifically documented by the World Health Organization, so there's no big deal what we are to discover except the fun we get by looking at the results.

The most interesting rule I got because of its simplicity, and the one I would like to share with you, may be taken as a "warning" (or a joke if you wish) and I can only speculate if the rule is true or not. The rule states the following:
If your Body Mass Index (BMI in SI units) is higher than 27.3 and you're at least 29 then you are diabetes positive.

For reference, the formula for BMI is simply to divide (your weight (kg)) for your (height (m) raised to the power of 2)). For instance, if you are 1.7m and 65kg the result should be approximately 22.49.
Additionally, the table that maps ranges to categories is the following:

Category - BMI range
Starvation- less than 15
Underweight - from 15 to 18.5
Normal - from 18.5 to 25
Overweight - from 25 to 30
Obese - from 30 to 40
Morbidly Obese - greater than 40

Of course this rule is very simple, and you shouldn't take it seriously, of course.
It is interesting however that it yielded an accuracy of 70% in my data set and the only thing I can speculate is that it may be revelatory of a pre-diabetic state or even a natural tendency for most (?) patients.

24 hours Web Development on Rails

I'm currently attending the Masters Degree in Informatics and Computing Engineering at FEUP and there's an amazing thing (NOT really now that I think about it again...) that I have to do preferably until the 23th of this month: developing a so called "home page".
I'm going to use the Ruby on Rails' Agile Web Development approach for the time being and I'll try to get everything up until there... if not, then I will use my trump card, which in portuguese language would be called "desenrascanço". I would really like to be able to translate this word but I don't really don't know that... sorry :) I already have something for the web page like the visual design, so... still much work left to do :)
More updates, about my crusade against time dealing with Rails and making a web page in 24 hours, coming soon...

Update at 22:06 (+1 day)
Well, it seems I got something working. One of the challenges was localization support, since I will be supporting 3 languages. I didn't spend too much time looking for rails plugins that provide localization support, but the ad hoc approach looked like a charm :) I pretty much used filters which select the correct language texts based on the current language.
Gotta go! I have a lot of localization still left to do!

DSAI 2007 - Software Development for Enhancing Accessibility and Fighting Info-exclusion

Today, I had the best experience of my life about being aware of a software quality attribute, often forgotten or not simply taken into account when developing or planning software, called Accessibility. I would even subjectively speculate that, although Accessibility is a subgroup of a larger group called Usability, the former one is so vast and complex that may have a life of its own.

I was invited to participate in the organization of a workshop and its presentation to address the problem of Usability and Accessibility of mobile communication/navigation devices.

Instead of describing in full detail the ideas/issues that came from brainstorming and many of the concepts which I've acquired by participating in this event, I will just present a list of them along with a brief comment for each:

•  Always consider an inclusive-design approach, i.e., if you consider your software product will have to work with all kinds of people with disabilities (e.g., visual impaired, paraplegic,  etc.), your product will naturally perform superb with all kinds of users, in terms of user interaction and experience;
  
• Even people who don't have any kind of disabilities can be often considered temporarily in that situation (e.g., imagine the scenario where you're driving a car: normally you are naturally less able to talk and listen to the other passengers in the car; your vision orientation is often directed to the front;  you cannot often take your feet off the car's brake or accelerator or remove one or two hands from the steering wheel... In this situation, what's the difference between a person without and a person with disabilities? Almost none);
• Allow the user to "blindly" interact with the navigation device and the reality that is presented to him, without even having to physically touch the device, by using the screen or hardware buttons (e.g., using speech recognition to instruct the device or ask from it information about the reality);
• When visual interaction is desired, it is of extreme importance to correctly but also easily have a matching between what can be observed from the reality and from the device display;
• and many other ideas/problems, so I placed the presentation online, for you to enjoy it :)

The Big World Syndrome

This is actually the worst title I could come up with for my first post in this blog.
Anyway, these past months I've been struggling to develop some decent and acceptable 3D computer graphics for embedded devices such as PDAs and PNAVs (Personal NAVigation devices) to be implemented in automobile navigation systems. Although there are not so many APIs available for this purpose (and even if there were!) there are so many challenges one has to be aware of and address, when developing applications for this kind of devices. For instance, there's no such thing as a FPU (Floating Point Unit) in most of them, which leaves us apparently with only one option, if we are to deal with high precision numbers for calculations: software floating point support. Unless you are OK with extremely low frame refresh rates, actually this is so slow that, in most cases, floating point software support is not an option. Other issues also arise from using this kind of devices, which are not relevant to this post or that I'm not (fortunately) still aware of.
The problem I've been addressing lately is what I like to call it The Big World Syndrome. If you want to get a big picture of this world, I invite you to close your eyes and imagine it for a while. Now open them... or you won't be able to read the rest of this post :) Now, think about this... If you are to represent everything in the world with an acceptable (high) precision, i.e. with an error not easily noticeable by the human eye, using very precision-limited numbers which are enough to represent the whole world but not to accommodate for all the calculations you have to perform until you reach the final result... you will eventually arrive at the same conclusion I did: that the world is to big to represent, using a "naive" approach. I'm still thinking about this issue, and I haven't still arrived at a final solution, but I'm addressing it using a little bit similar approach that has been followed by other projects like GeoVRML. I've been influenced by some of the ideas and came up with different ones. It basically defines a way to declare coordinates for the world, using not only one global coordinate system but many of them using relative coordinates. Assuming the fact that when you're looking closer at a piece of the world map, you want to view it in higher detail, using these local coordinate systems you will get much higher precision.
Of course this is just the tip of the iceberg since we will have to deal with some of the trade-offs involved.